Navigation instructions

ABSTRACT

Systems and methods are provided for improved navigation instructions. In one implementation instructions between two locations can be computed, the instructions can be processed in relation to previously computed instructions between the same locations and/or a previously traveled route between the same locations to determine disparitie(s) therebetween, and a notification can be generated based on the disparitie(s). In another implementation, one set of instructions between two locations can be received, another set of instructions between two other locations can be received, the sets of instructions can be processed to determine disparities between them with respect to one or more locations, a notification can be generated based on the one or more disparities, and the notification can be provided in relation to the location(s).

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Patent Application No.62/042,244, filed Aug. 26, 2014, U.S. Patent Application No. 62/047,649,filed Sep. 9, 2014, U.S. Patent Application No. 62/063,152, filed Oct.13, 2014 and U.S. Patent Application No. 62/066,378, filed Oct. 21, 2014and is also a continuation-in-part of International Patent ApplicationNo. PCT/IB2013/001582, filed Jun. 21, 2013, which claims the benefit of:U.S. Patent Application No. 61/662,659, filed Jun. 21, 2012, U.S. PatentApplication No. 61/676,704, filed Jul. 27, 2012, U.S. Patent ApplicationNo. 61/694,172, filed Aug. 28, 2012, U.S. Patent Application No.61/694,180, filed Aug. 28, 2012, U.S. Patent Application No. 61/704,113,filed Sep. 21, 2012, U.S. Patent Application No. 61/731,394, filed Nov.29, 2012, U.S. Patent Application No. 61/732,693, filed Dec. 3, 2012,U.S. Patent Application No. 61/793,633, filed Mar. 15, 2013, U.S. PatentApplication No. 61/815,998, filed Apr. 25, 2013, U.S. Patent ApplicationNo. 61/825,034, filed May 19, 2013, U.S. Patent Application No.61/825,358, filed May 20, 2013, and U.S. Patent Application No.61/829,967, filed May 31, 2013, and is also a continuation-in-part ofInternational Patent Application No. PCT/US2014/052583, filed Aug. 25,2014, which claims the benefit of: U.S. Patent Application No.61/869,548, filed Aug. 23, 2013, U.S. Patent Application No. 61/875,100,filed Sep. 8, 2013, U.S. Patent Application No. 61/896,398, filed Oct.28, 2013, U.S. Patent Application No. 61/949,713, filed Mar. 7, 2014,U.S. Patent Application No. 61/951,478, filed Mar. 11, 2014, and U.S.Patent Application No. 61/973,278, filed Apr. 1, 2014, each of which isincorporated herein by reference in their respective entireties.

TECHNICAL FIELD

This disclosure relates generally to the field of mobile deviceidentification, and, in particular, to computer-implemented systems andmethods for mobile device context aware determinations.

BACKGROUND

There are approximately 4.6 billion cellular phone subscriptions in theworld over which it is estimated that more than 2 trillion text (SMS)messages are sent annually. There are also over 800 milliontransportation vehicles in the world. The magnitude of these statisticsindicates that cellular phone use in vehicles is inevitable and islikely to remain quite common, unless preventative measures are taken.

Drivers using a hand-held cellular phone or smartphone for talking, textmessaging, and/or for executing other applications or ‘apps’ whiledriving has become a problem of near-epidemic proportions. Studies ondistracted driving have shown that by talking on a cell phone, a driverincreases his/her risk of a crash by a factor of four. Even worse,sending text messages increases a driver's crash risk 23-fold.Additionally, studies have shown that the temptation to use a cellularphone for texting, talking, and other activities while operating avehicle is not limited to younger drivers—adult drivers have been shownto text more often than younger ones.

In response to this growing concern and danger, numerous regulatoryactions have been put in place to attempt to mitigate such phone-baseddistractions to drivers. For example, in the United States, thirtystates have banned drivers of vehicles from texting, and many havesubsequently increased the penalties for such violations.Driving-while-texting has also been banned throughout Europe and manyother countries around the world. Additionally, talking on a hand-heldcellular phone while driving a vehicle has been banned in eight USstates, and such cell phone use has been banned in all of Europe and inmany other countries.

The effectiveness of these laws alone, without an effective means ofenforcement, is questionable. Being that cellular phones are generallysmall and discreet and drivers are frequently in motion, it is oftendifficult for law enforcement personnel to effectively police for suchviolations. Indeed, statistics show that crashes arising from cellularphone-based distractions are increasing as the popularity of suchdevices increases.

Given the easy accessibility of cell phones to drivers, many drivers'apparent desire to operate their cellular phones while driving, and thedifficulties attendant with enforcing laws prohibiting cellular phoneuse, it is likely that drivers will continue to use cellular phones fortexting, talking, and/or other activities (e.g., playing games orrunning applications), for the foreseeable future.

Moreover, it can be appreciated that the usage of mobile devices invarious locations and/or settings can be detrimental on a number oflevels. For instance, anecdotal evidence suggests that the proliferationof mobile devices such as smartphones has resulted in an increase ofmobile device usage by students during classes/lectures, serving todistract such students from properly absorbing the material beingtaught. Additionally, many students have become adept at using suchdevices discreetly, resulting in many instances of cheating beingfacilitated through the use of mobile devices.

It is with respect to these and other considerations that the disclosuremade herein is presented.

SUMMARY

Technologies are presented herein in support of a system and method forimproved navigation instructions. According to one aspect, one or morenavigation instructions between a first location and a second locationcan be computed, the one or more navigation instructions can beprocessed in relation to at least one of (a) one or more previouslycomputed navigation instructions between the first location and thesecond location or (b) a previously traveled route between the firstlocation and the second location to determine one or more disparitiesbetween the one or more navigation instructions and the at least one of(a) one or more previously computed navigation instructions between thefirst location and the second location or (b) a previously traveledroute between the first location and the second location, and one ormore notifications can be generated based on the one or moredisparities.

According to another aspect, a first set of navigation instructions canbe received, the first set of navigation instructions includingnavigation instructions from a first origin to a first destination, asecond set of navigation instructions can be received, the second set ofnavigation instructions including navigation instructions from a secondorigin to a second destination, the first set of navigation instructionsand the second set of navigation instructions can be processed todetermine one or more disparities between the first set of navigationinstructions and the second set of navigation instructions with respectto one or more locations, one or more notifications can be generatedbased on the one or more disparities, and the one or more notificationscan be provided in relation to the one or more locations.

These and other aspects, features, and advantages can be appreciatedfrom the accompanying description of certain embodiments and theaccompanying drawing figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level diagram illustrating an exemplary configurationof an in-vehicle determination system;

FIGS. 2A-2C are flow diagrams showing routines that illustrate broadaspects of methods for determining an in-vehicle role of a user and/oran in-vehicle location of a mobile device in accordance with variousexemplary embodiments disclosed herein;

FIG. 3 is a flow diagram showing a routing that illustrates a broadaspect of a method for enabling, disabling and/or modifying at least afeature of a mobile device in accordance with at least one exemplaryembodiment disclosed herein;

FIG. 4 is a flow diagram showing a routine that illustrates a broadaspect of a method for determining an in-vehicle role of a user of amobile device and/or a handheld state of a mobile device and/or avehicle class of a vehicle containing the first mobile device using acentral machine in accordance with at least one exemplary embodimentdisclosed herein;

FIG. 5 is a flow diagram showing a routine that illustrates a broadaspect of a method for determining a vehicle class of a vehicle using amobile device in accordance with at least one exemplary embodimentdisclosed herein;

FIG. 6 is a flow diagram showing a routine that illustrates a broadaspect of a method of determining a handheld state a mobile device inaccordance with at least one embodiment disclosed herein;

FIG. 7 is a flow diagram showing a routine that illustrates a broadaspect of a method of restricting operation of a mobile device inaccordance with at least one embodiment disclosed herein;

FIG. 8 is a flow diagram showing a routine that illustrates a broadaspect of another method of restricting operation of a mobile device inaccordance with at least one embodiment disclosed herein;

FIG. 9A is a diagram depicting an exemplary relative coordinate systemof a mobile device;

FIG. 9B is a diagram depicting exemplary relative accelerations andgyroscopic rotations of a mobile device;

FIG. 9C is a diagram depicting an exemplary gyroscopic sign convention,as used herein;

FIG. 10 is a diagram depicting an exemplary coordinate system used inrelation to a vehicle;

FIGS. 11A-B are diagrams depicting a mobile device and its respectiveexemplary coordinate system in various orientations in relation to a carand its exemplary respective coordinate system;

FIG. 12 is a flow diagram showing a routine that illustrates a broadaspect of another method of restricting operation of a mobile device inaccordance with at least one embodiment disclosed herein;

FIG. 13 is a flow diagram showing a routine that illustrates a broadaspect of another method of restricting operation of a mobile device inaccordance with at least one embodiment disclosed herein;

FIG. 14 is a flow diagram showing a routine that illustrates a broadaspect of a method for orienting a coordinate system of a mobile devicein accordance with at least one embodiment disclosed herein;

FIG. 15 is a flow diagram is described showing a routine thatillustrates a broad aspect of a method for selectively restricting anoperation of a mobile device in accordance with at least one embodimentdisclosed herein;

FIG. 15A is an exemplary lock screen, in accordance with at least oneembodiment disclosed herein;

FIG. 15B is an exemplary visual capture that can be processed toidentify a presence of a fastened seatbelt, in accordance with at leastone embodiment disclosed herein;

FIG. 15C depicts the “required orientation” of a mobile device, inaccordance with at least one embodiment disclosed herein;

FIG. 15D depicts an exemplary screenshot showing visual feedback thatcan be provided to a user during authentication in accordance with atleast one embodiment disclosed herein;

FIG. 15E depicts an exemplary screenshot showing visual feedback thatcan be provided to a user during authentication in accordance with atleast one embodiment disclosed herein;

FIG. 15F depicts a mobile device, and specifically the locations of theforward-facing and rear-facing cameras of the mobile device, inaccordance with at least one embodiment disclosed herein;

FIG. 15G is an illustration depicting a 90 degree angle of incidencebetween the user's eyes/gaze/face/smile etc. and a mobile device, inaccordance with at least one embodiment disclosed herein;

FIGS. 15H-T depict exemplary aspects of an authentication sequence inaccordance with at least one embodiment disclosed herein;

FIG. 16 is a flow diagram showing a routine that illustrates a broadaspect of a method for selectively restricting operation of a mobiledevice in accordance with at least one embodiment disclosed herein;

FIG. 17 is a flow diagram showing a routine that illustrates a broadaspect of a method for authenticating an in vehicle role of a user of amobile device and/or modifying a restriction of a mobile device inaccordance with at least one embodiment disclosed herein;

FIG. 17A is a flow diagram showing particular aspects of the validationstep of FIG. 17, in accordance with at least one embodiment disclosedherein;

FIG. 17B is an illustration depicting an orientation of a mobile devicein relation to a typical line of sight of the driver in a moving car, inaccordance with at least one embodiment disclosed herein,

FIG. 18 is a flow diagram is described showing a routine thatillustrates a broad aspect of a method for selectively restricting anoperation of and/or selectively modifying a restriction employed atmobile device, in accordance with at least one embodiment disclosedherein;

FIG. 19 depicts an exemplary determination of orientation of a devicebased on visual capture(s) in accordance with at least one embodimentdisclosed herein;

FIG. 20 depicts the orientation and/or location of mobile device inorder to provide the requisite stability described herein, in accordancewith at least one embodiment disclosed herein;

FIG. 21 is a flow diagram showing a routine that illustrates a broadaspect of a method for selectively restricting a mobile device, inaccordance with at least one embodiment disclosed herein;

FIG. 22 is a flow diagram showing a routine that illustrates a broadaspect of a method for eliciting an authentication at a mobile device,in accordance with at least one embodiment disclosed herein;

FIG. 23 is a flow diagram showing a routine that illustrates a broadaspect of a method for eliciting an authentication at a mobile device,in accordance with at least one embodiment disclosed herein;

FIG. 24 is a flow diagram showing a routine that illustrates a broadaspect of a method for selectively modifying a restriction employed at amobile device, in accordance with at least one embodiment disclosedherein;

FIG. 25 is a flow diagram showing a routine that illustrates a broadaspect of a method for selectively projecting outputs at a mobiledevice, in accordance with at least one embodiment disclosed herein;

FIG. 26 is a flow diagram showing a routine that illustrates a broadaspect of a method for selectively configuring overt operation of amobile device, in accordance with at least one embodiment disclosedherein;

FIG. 27 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 28 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 29 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 30 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 31 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 32 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 33 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 34 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 35 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 36 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 37 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 38 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 39 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 40 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 41 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 42 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 43 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein

FIG. 44 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 45 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 46 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 47 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 48 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 49 depicts an exemplary implementation of one or more aspectsdescribed herein;

FIG. 50 depicts an exemplary implementation of one or more aspectsdescribed herein;

FIG. 51 depicts an exemplary implementation of one or more aspectsdescribed herein;

FIG. 52 depicts an exemplary implementation of one or more aspectsdescribed herein;

FIG. 53 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 54 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 55 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 56 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 57 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 58 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 59 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 60 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 61 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 62 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 63 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 64 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 65 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 66 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 67 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 68 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 69 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 70 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 71 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 72 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 73 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 74 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 75 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 76 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 77 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 78 depicts an exemplary implementation of one or more aspectsdescribed herein;

FIG. 79 depicts an exemplary implementation of one or more aspectsdescribed herein;

FIG. 80 depicts an exemplary implementation of one or more aspectsdescribed herein;

FIG. 81 depicts an exemplary implementation of one or more aspectsdescribed herein;

FIG. 82 depicts an exemplary implementation of one or more aspectsdescribed herein;

FIG. 83 depicts an exemplary implementation of one or more aspectsdescribed herein;

FIG. 84 depicts an exemplary implementation of one or more aspectsdescribed herein;

FIG. 85 depicts an exemplary implementation of one or more aspectsdescribed herein;

FIGS. 86A-C depict exemplary implementations of one or more aspectsdescribed herein;

FIGS. 87A-E depict exemplary implementations of one or more aspectsdescribed herein;

FIGS. 88A-E depict exemplary implementations of one or more aspectsdescribed herein;

FIGS. 89A-C depict exemplary implementations of one or more aspectsdescribed herein;

FIGS. 90A-E depict exemplary implementations of one or more aspectsdescribed herein;

FIGS. 91A-C depict exemplary implementations of one or more aspectsdescribed herein;

FIGS. 92A-E depict exemplary implementations of one or more aspectsdescribed herein;

FIGS. 93A-D depict exemplary implementations of one or more aspectsdescribed herein;

FIGS. 94A-D depict exemplary implementations of one or more aspectsdescribed herein;

FIGS. 95A-C depict exemplary implementations of one or more aspectsdescribed herein;

FIGS. 96A-C depict exemplary implementations of one or more aspectsdescribed herein;

FIG. 97 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein; and

FIG. 98 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

By way of overview and introduction, the present disclosure detailssystems and methods for determining various user roles and actions asthey relate to the operation of a mobile device within a vehicle such asa car. Being that the usage of mobile devices while driving has beenidentified as a significant cause of car crashes, in addition to lawsthat have been enacted preventing certain use of mobile phones whiledriving, various systems and methods are provided herein which serve toidentify the user of a particular mobile device (for instance, withrespect to their role as a driver or passenger in the car), to identifyvarious aspects of the usage of the device itself (for instance that thedevice is executing a text messaging application), and to identifyinstances when a mobile device deviates from its expected or regularoperation.

As will be described in detail herein, many of these identificationsand/or determinations are made possible through various sensors,components, and elements that are integrated within and/or accessible toa mobile device. As is well known to those of ordinary skill in the art,contemporary smartphones incorporate a plethora of sensors, includingaccelerometers, GPS receivers, and gyroscopes. Various inputs and/ornotifications can be received from these sensors, components, andelements, and can further be processed in a number of ways in order toarrive at various conclusions regarding, among others, the user of themobile device (such as whether the user is a driver or passenger in acar) and/or the status of the mobile device itself, and variousprobabilities can be ascribed to the conclusions. The operation of themobile device can further be adjusted based on such conclusions, forexample, disabling or limiting the operation of a mobile device uponreaching a likely conclusion that the device is being operated by a userwho is driving a car.

It will also be appreciated that the systems and methods disclosedherein can be arranged and/or deployed across a number of scenarios. Inone scenario, the systems and methods can be principally employed at amobile device itself, such as in the form of a mobile application or‘app’ executing on the mobile device. In other scenarios, a centralmachine such as a server in communication with a mobile device canemploy the present systems and methods. Such a centralized architecturecan enable efficient processing and use of a larger database of userdetermination characteristics, eliminates power constraints and enablesthird parties, such as law-enforcement agencies and/or insurancecompanies, to easily monitor and/or adjust the operation of variousmobile devices.

Moreover, it can be appreciated that today, over 70% of teenagers in thedeveloped world own mobile devices, and most bring those devices toschool every day. The ability to use these devices clandestinely inclass results in student distraction, cheating on tests, and frequentdisruptions of the learning environment. The inappropriate use of mobiledevices in class has become one of the major problems in westerneducational systems today, affecting many millions of students andteachers in a very direct way.

The systems and methods described herein define a solution that rendersthe surreptitious use of mobile devices in school impossible, directlyimproving student attention and learning, and empowering educators todecide how (if at all) they may be used in classrooms. In doing so, thepresent systems and methods can limit distraction without interferingwith legitimate device use, which until now has been a major barrier tothe adoption of other proposed solutions.

The following detailed description is directed to systems and methodsfor determining an in-vehicle role of a user of a mobile device,selectively restricting a mobile device, and/or configuring variousoperations of a mobile device. The referenced systems and methods arenow described more fully with reference to the accompanying drawings, inwhich one or more illustrated embodiments and/or arrangements of thesystems and methods are shown. The systems and methods are not limitedin any way to the illustrated embodiments and/or arrangements as theillustrated embodiments and/or arrangements described below are merelyexemplary of the systems and methods, which can be embodied in variousforms, as appreciated by one skilled in the art. Therefore, it is to beunderstood that any structural and functional details disclosed hereinare not to be interpreted as limiting the systems and methods, butrather are provided as a representative embodiment and/or arrangementfor teaching one skilled in the art one or more ways to implement thesystems and methods. Accordingly, aspects of the present systems andmethods can take the form of an entirely hardware embodiment, anentirely software embodiment (including firmware, resident software,micro-code, etc.) or an embodiment combining software and hardware. Oneof skill in the art can appreciate that a software process can betransformed into an equivalent hardware structure, and a hardwarestructure can itself be transformed into an equivalent software process.Thus, the selection of a hardware implementation versus a softwareimplementation is one of design choice and left to the implementer.Furthermore, the terms and phrases used herein are not intended to belimiting, but rather are to provide an understandable description of thesystems and methods.

The terms “determining,” “determine,” and “determination” as used hereinare intended to encompass the determination, identification,computation, calculation, and/or selection, with any degree of certaintyor precision, and/or any other such operation, function, or action as itrelates to the determination, identification, and/or selection of a userof a device such as a mobile device, an in-vehicle role of a user of adevice such as a mobile device, a vehicle or vehicle model/type/class, adevice or device model/type/class (e.g., handheld or wired), anoperation and/or operation state of a device, and/or any other suchsimilar or related operation, function, or action.

The terms “identifying event” and “identifying events” as used hereinare intended to encompass one or more occurrences or instances ofevents, stimuli, or phenomena, including explicitly the perceivedcoordinated or correlated occurrence or instance of two or more suchevents, stimuli, and/or phenomena, such as those originating at one ormore devices. It should be understood that the referenced occurrences orinstances of events, stimuli, or phenomena include single/singularevents, stimuli, or phenomena as well as a set or series of multipleevents, stimuli, or phenomena over a period of time. In addition, thereferenced occurrences or instances of events, stimuli, or phenomenashould also be understood to include one or more coordinations orcorrelations of the occurrence or instance of any number of such events,stimuli, and/or phenomena over any period of time.

The terms “user interface” and “user interfaces” as used herein areintended to encompass one or more input devices, software modulesexecuting in conjunction with one or more operating systems and/or inputdevices, or any other such similar or related device, accessory,apparatus, and/or software application or module that enable orfacilitate input and/or interaction with a computing device.

The terms “detect,” “detected,” “detects,” “detecting,” “detection,” and“detections” as used herein are intended to encompass the detection,measurement, and/or receipt, with any degree of certainty or precision,one or more occurrences or instances of events, stimuli, phenomena, orany other such similar or related inputs that are detectable through oneor more devices, implements or apparatuses.

The term “processing” as used herein is intended to encompass comparing,analyzing, weighing, correlating and/or computing one or more dataitems, elements, or structures, individually or in conjunction with oneanother, using a digital processor in conjunction with one or moresoftware modules and/or applications.

The term “communicatively coordinated” as used herein is intended toencompass direct or indirect communication between two or more devices,accessories, and/or apparatuses, expressly including communicationsbetween a first device and a central machine, wherein the centralmachine is in turn in communication at some interval with a seconddevice. In such a scenario, though the first device and the seconddevice are not, necessarily, in direct or indirect communication withone another, it can be said that they are communicatively coordinatedwith one another by virtue of their mutual connection to the referencedcentral machine.

The terms “feature” and “features” as used herein are intended toencompass operations, functions, activities, or any other such similaror related actions, whether automated/automatic or user-initiated, thatoccur at or in conjunction with one or more devices, machines,applications, and/or apparatuses.

The terms “notification” and “notifications” as used herein are intendedto encompass one or more messages, transmissions, and/or data packets,such as electronic messages, which contain one or more data elements(such as inputs) related or relevant to one or more of the steps,operations, and/or processes disclosed herein. An illustration of onesuch notification can be one or more electronic messages which containinformation or data reflecting a first input from an accelerometer, agyroscope, and/or a GPS receiver at a mobile device. Such inputs can begrouped together into one or more notifications, and these notificationscan in turn be transmitted to and/or received by other devices (such asa central machine) where they can be further processed.

The terms “vehicle class” and “vehicle classes” as used herein areintended to encompass one or more types, categories, and/or models ofvehicle. By way of example, airplanes, trains, automobiles, motorcycles,and boats can all be said to be different vehicle classes. By way offurther example, sub-categories within a given vehicle class can also beunderstood to be different vehicle classes. Thus, the automobile vehicleclass can be further sub-divided into further vehicle classes such assedans, vans, sport utility vehicles (SUVs), and convertibles. Thesesub-categories can also be said to be vehicle classes within the meaningof the term as used herein.

The terms “operation state” and “operation states” as used herein areintended to encompass the states of a device, including any and alloperations, functions, capacities, and/or capabilities, including,explicitly, a set and/or series of any number of operations, functions,capacities, and/or capabilities, that can be achieved by and/or inconjunction with a device, such as a mobile device. Examples of anoperation state include, but are not limited to: an execution of anapplication (such as an internet browser application) at a mobiledevice, a transmission of a notification (such as sending a text messageor email message), a capacity to receive text messages, and a capabilityto type text using a keyboard. Accordingly, the various transformations,adjustments, and/or modifications disclosed herein that relate to anoperation state and/or operation states should be understood to refer tosuch transformations, adjustments, and/or modifications that pertain topractically any and all operations, functions, capacities, and/orcapabilities that can be achieved by and/or in conjunction with adevice, such as a mobile device.

The terms “handheld state” and “handheld states” as used herein areintended to encompass one or more states of a mobile device with respectto whether or not a user is in direct or indirect physical contact withthe device. For example, the handheld state of a device in instanceswhere a user holds the device in his/her hand, carries the device inhis/her pocket, and/or balances the device on his/her knee can all besaid to be “handheld.” By way of further example, the handheld state ofa device in instances where the device is positioned in a dock orcradle, and/or is otherwise not in direct or indirect contact with auser can be said to be “non-handheld.”

The terms “operational capacity” and “operational capacities” as usedherein are intended to encompass one or more operation states of amobile device, particularly with respect to a central machine such as aserver. By way of example, an operational capacity of a mobile devicecan be a voice or data connection that is provided to a mobile devicethrough a central machine, such as that of a voice/data serviceprovider. Accordingly, it can be appreciated that a transformation,modification, and/or adjustment of such an operational capacitypreferably entails such a transformation, modification, and/oradjustment that is initiated and/or effected by a central machine,preferably in relation to a mobile device. For example, a centralmachine can transmit an instruction and/or notification to a mobiledevice, such instruction/notification directing the transformation,modification, and/or adjustment be implemented at the mobile device. Byway of further example, a central machine can implement atransformation, modification, and/or adjustment at the central machineitself, wherein such a transformation, modification, and/oradjustment—such as the stopping of voice and/or data connections to amobile device—ultimately effect the functionality of the device itself.In both such cases it can be said that the central machine hastransformed, modified, and/or adjusted the operational capacity of themobile device.

The terms “user” and “users” as used herein are intended to encompassone or more individuals, persons, and/or entities whose presence adevice or machine can preferably be directly or indirectly aware. Itshould be understood that while in certain scenarios a user can interactwith a device, in other scenarios a particular individual, person,and/or entity can be said to be a “user” within the context of thepresent disclosure, despite not interacting with a particular device.

The terms “tactile sensor” and “tactile sensor(s)” as used herein areintended to encompass one or more buttons, touchscreens, and/orcomponents that enable a user to interact with a device in a tactilefashion. Examples of such tactile sensors include, but are not limitedto, buttons (such as those that comprise a keyboard), switches, as wellas touch screen displays (such as capacitive and resistive displays)which both display information and allow the tactile interaction withsuch information. It should be further understood that such tactilesensors are preferably further capable of perceiving a plurality ofsimultaneous tactile interactions. Examples of such functionalityinclude mutlitouch technologies, as are known to those of ordinary skillin the art.

The terms “visual capture” and “visual captures” as used herein areintended to encompass one or more operations, functions, and/or actionsthat relate to the optical perception and/or documentation of one ormore visual items, elements, and/or phenomena. Examples of such visualcaptures include, but are not limited to, photographs, images, videos,and/or any other such method of visual perception and/or documentation.Accordingly, it can be appreciated that certain visual capturescorrespond to a single instance (such as a photograph) while othervisual captures correspond to multiple instances (such as a series ofphotographs and/or a video).

The term “in-vehicle role indicator” as used herein is intended toencompass one or more items, elements, and/or indicators that relate toone or more aspects associated with and/or corresponding to thein-vehicle role of a user in a vehicle (e.g., whether a user is or isnot a driver, is or is not a passenger, etc.). For example, one suchin-vehicle role indicator is identifying in a picture of two hands of adriver grasping the steering wheel of a vehicle. Using one or moreoptical recognition methods, such as those known to one of ordinaryskill in the art, one or more images and/or videos can be processed inorder to identify the presence of two hands grasping a steering wheel,thus indicating that a particular vehicle is being operated by a driverusing two hands and therefore it can be reasonable concluded that theuser who took such an image is not the driver. By way of furtherexample, another such in-vehicle role indicator can be capturing apicture that can be processed to identify that a seatbelt extends fromthe right shoulder to left thigh of the wearer. Such an identificationalso reasonably suggests that the wearer is not a driver (as theseatbelt of a driver traditionally extends from the left shoulder to theright thigh).

It should be further understood that while the various computing devicesand machines referenced herein, including but not limited to the firstmobile device, the second mobile device, the central machine, or anyother such similar or related devices or machines are referred to hereinin a as individual/single devices and/or machines, in certainarrangements the referenced devices and machines, and their associatedand/or accompanying operations, features, and/or functionalities can bearranged or otherwise employed across any number of devices and/ormachines, such as over a network connection, as is known to those ofskill in the art.

In addition, it should be understood that while the term “input” is usedherein in the singular form, this is merely for the sake of clarity andconvention. However, the referenced terms should be understood toencompass both singular inputs as well as a plurality (two or more)inputs, such as a set of inputs.

It should be understood that the terms “lateral acceleration,”“x-acceleration,” and “x-axis acceleration” as used herein are usedinterchangeably, and should thus be understood to possess the samemeaning and connotation. Additionally, the terms “forward acceleration,”“y-acceleration,” and “y-axis acceleration” as used herein are usedinterchangeably and should thus be understood to possess the samemeaning and connotation. In addition, the terms “upward acceleration,”“z-axis acceleration,” “z-acceleration” as used herein are usedinterchangeably and should thus be understood to possess the samemeaning and connotation.

It should also be understood that the terms “yaw,” “gyroscopic yaw,”“angular velocity around the z-axis,” and “rotation around the z-axis”as used herein are used interchangeably, and should thus be understoodto possess the same meaning and connotation. In addition, the terms“roll,” “gyroscopic roll,” “angular velocity around the y-axis,” and“rotation around the y-axis,” as used herein are used interchangeably,and should thus be understood to possess the same meaning andconnotation. Additionally, the terms “pitch,” “gyroscopic pitch,”“angular velocity around the x-axis,” and “rotation around the x-axis”as used herein are used interchangeably, and should thus be understoodto possess the same meaning and connotation.

An exemplary computer system is shown as a block diagram in FIG. 1 whichis a high-level diagram illustrating an exemplary configuration of adetermination system 100. In one arrangement, mobile device 105 can be aportable computing device such as a mobile phone, smartphone, or PDA. Inother arrangements, mobile device 105 can be a tablet computer, a laptopcomputer, a personal computer, or an in-vehicle computer (e.g., ECU/OBD)though it should be understood that mobile device 105 of determinationsystem 100 can be practically any computing device capable of embodyingthe systems and/or methods described herein.

Mobile device 105 of determination system 100 includes a control circuit140 which is operatively connected to various hardware and softwarecomponents that serve to enable operation of the determination system100. The control circuit 140 is operatively connected to a processor 110and a memory 120. Processor 110 serves to execute instructions forsoftware that can be loaded into memory 120. Processor 110 can be anumber of processors, a multi-processor core, or some other type ofprocessor, depending on the particular implementation. Further,processor 110 can be implemented using a number of heterogeneousprocessor systems in which a main processor is present with secondaryprocessors on a single chip. As another illustrative example, processor110 can be a symmetric multi-processor system containing multipleprocessors of the same type.

Preferably, memory 120 and/or storage 190 are accessible by processor110, thereby enabling processor 110 to receive and execute instructionsstored on memory 120 and/or on storage 190. Memory 120 can be, forexample, a random access memory (RAM) or any other suitable volatile ornon-volatile computer readable storage medium. In addition, memory 120can be fixed or removable. Storage 190 can take various forms, dependingon the particular implementation. For example, storage 190 can containone or more components or devices. For example, storage 190 can be ahard drive, a flash memory, a rewritable optical disk, a rewritablemagnetic tape, or some combination of the above. Storage 190 also can befixed or removable.

One or more software modules 130 are encoded in storage 190 and/or inmemory 120. The software modules 130 can comprise one or more softwareprograms or applications having computer program code or a set ofinstructions executed in processor 110. Such computer program code orinstructions for carrying out operations for aspects of the systems andmethods disclosed herein can be written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Java, Smalltalk, (++ or the like and conventionalprocedural programming languages, such as the “C” programming languageor similar programming languages. The program code can execute entirelyon the mobile device 105, partly on mobile device 105, as a stand-alonesoftware package, partly on mobile device 105 and partly on a remotecomputer/device or entirely on the remote computer/device or server. Inthe latter scenario, the remote computer can be connected to mobiledevice 105 through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection can be made to anexternal computer (for example, through the Internet using an InternetService Provider).

Software modules 130, including program code/instructions, are locatedin a functional form on one or more computer readable storage devices(such as memory 120 and/or storage 190) that can be selectivelyremovable. The software modules 130 can be loaded onto or transferred tomobile 105 for execution by processor 110. It can also be said that theprogram code of software modules 130 and one or more computer readablestorage devices (such as memory 120 and/or storage 190) form a computerprogram product.

It should be understood that in some illustrative embodiments, one ormore of software modules 130 can be downloaded over a network to storage190 from another device or system via communication interface 150 foruse within determination system 100. For instance, program code storedin a computer readable storage device in a server can be downloaded overa network from the server to determination system 100.

Preferably, included among the software modules 130 is a determinationmodule 170 that is executed by processor 110. During execution of thesoftware modules 130, and specifically the determination module 170, theprocessor 110 configures the control circuit 140 to determine anin-vehicle role of a user of the mobile device 105, as will be describedin greater detail below. It should be understood that while softwaremodules 130 and/or determination module 170 can be embodied in anynumber of computer executable formats, preferably software modules 130and/or determination module 170 comprise one or more applications or‘apps’ that are configured to be executed at mobile device 105 and/or inrelation to mobile device 105. In other arrangements, software modules130 and/or determination module 170 are incorporated and/or integratedwithin operating system 176. Furthermore, in certain arrangements,software modules 130 and/or determination module 170 can be configuredto execute at the request or selection of a user of mobile device 105(or any other such user having the ability to execute a program inrelation to mobile device 105, such as a network administrator), whilein other arrangements mobile device 105 can be configured toautomatically execute software modules 130 and/or determination module170, without requiring an affirmative request to execute. The advantagesof such an automatic arrangement can be appreciated in context of aregulatory scheme that mandates or recommends that software modules 130and/or determination module 170 be executed by a mobile device 105 someor all of the time, in furtherance of a campaign to improve driversafety. It should also be noted that while FIG. 1 depicts memory 120oriented on control circuit 140, in an alternate arrangement, memory 120can be operatively connected to the control circuit 140. In addition, itshould be noted that other software modules (such as user interface 172and operating system 176) and other information and/or data relevant tothe operation of the present systems and methods (such as database 174)can also be stored on storage 190, as will be discussed in greaterdetail below.

A communication interface 150 is also operatively connected to controlcircuit 140. Communication interface 150 can be any interface thatenables communication between the mobile device 105 and externaldevices, machines and/or elements. Preferably, communication interface150 includes, but is not limited to, a modem, a Network Interface Card(NIC) an integrated network interface, a radio frequencytransmitter/receiver (e.g., Bluetooth, cellular, NFC) a satellitecommunication transmitter/receiver, an infrared port, a USB connection,or any other such interfaces for connecting mobile device 105 to othercomputing devices and/or communication networks such as the Internet.Such connections can include a wired connection or a wireless connection(e.g. 802.11) though it should be understood that communicationinterface 150 can be practically any interface that enablescommunication to/from the control circuit 140.

At various points during the operation of determination system 100,mobile device 105 can communicate with one or more mobile devices 160A-N(collectively mobile devices 160). The mobile devices 160 transmitand/or receive data to/from the mobile device 105, thereby preferablyenhancing the operation of the determination system 100, as will bedescribed in greater detail below. It should be understood that mobiledevices 160 can be in direct communication with mobile device 105,indirect communication with mobile device 105, and/or can becommunicatively coordinated with mobile device 105, as will be describedin greater detail below. While mobile device 160 can be practically anydevice capable of communication with mobile machine 105, in thepreferred embodiment mobile device 160 is a handheld/portable computer,smartphone, personal digital assistant (PDA), tablet computer, and/orany portable device that is capable of transmitting and receiving datato/from mobile device 105. It should also be appreciated that in manyarrangements, mobile device 160 will be substantially identical, from astructural and functional perspective, to mobile device 105.

It should be noted that while the FIG. 1 depicts the determinationsystem 100 with respect to mobile device 160A and mobile device 160N, itshould be understood that any number of mobile devices 160 can interactwith determination system 100 in the manner described herein.

Also preferably connected to and/or in communication with controlcircuit 140 are one or more sensors 145A-145N (generically sensors 145).Generally, sensors 145 are various components, devices, and/or receiversthat are preferably incorporated within and/or in communication withmobile device 105. Sensors 145 preferably detect one or more stimuli,phenomena, or any other such inputs, as will be described in greaterdetail below. Examples of such sensors 145 include, but are not limitedto, an accelerometer 145A, a gyroscope 145B, a GPS receiver 145C, amicrophone 145D, a magnetometer 145E, a camera 145F, a light sensor145G, a temperature sensor 145H, an altitude sensor 145I, a pressuresensor 145J, a proximity sensor 145K, a near-field communication (NFC)device 145L, a compass 145M, and a tactile sensor 145N. As will bedescribed in greater detail below, mobile device 105 can preferablyreceive one or more inputs from one or more sensors 145 in order todetermine an in-vehicle role of a user of mobile device 105 and/or toselectively restrict the operation of the mobile device.

In certain arrangements, one or more external databases and/or servers162 are also in communication with mobile device 105. As will bedescribed in greater detail below, database/server 162 is preferably acomputing and/or storage device, and/or a plurality of computing and/orstorage devices, that contain(s) information, such as determinationcharacteristics, that can be relevant to the determination of anin-vehicle role of a user of mobile device 105.

Additionally, in certain arrangements a vehicle data system 164, such asan on board diagnostic (OBD) computer or computing device (e.g., OBD-I,OBD-II), an engine control unit (ECU), a roll system, an airbag system,a seat-weight sensor system, a seat-belt sensor system, and/or ananti-lock braking system (ABS) can also be in communication with mobiledevice 105. Vehicle data system 164 preferably provides data and/orinformation from the vehicle itself that can also be relevant to variousdeterminations disclosed herein, such as the determination of anin-vehicle role of a user of mobile device 105, as will be described ingreater detail below.

At this juncture it should be noted that in certain arrangements, suchas the one depicted in FIG. 1, mobile devices 160, database/server 162,and/or vehicle data system 164 can be in periodic or ongoingcommunication with mobile device 105 thorough a computer network such asthe Internet 166. Although not depicted in FIG. 1, it should beunderstood that in certain other arrangements, mobile devices 160,database/server 162, and/or vehicle data system 164 can be in periodicor ongoing direct communication with mobile device 105, such as throughcommunications interface 150, thus not requiring the presence of anetwork (such as the Internet 166) in order to initiate and maintaincommunications.

In the description that follows, certain embodiments and/or arrangementsare described with reference to acts and symbolic representations ofoperations that are performed by one or more devices, such as thedetermination system 100 of FIG. 1. As such, it will be understood thatsuch acts and operations, which are at times referred to as beingcomputer-executed, include the manipulation by the processor of thecomputer of electrical signals representing data in a structured form.This manipulation transforms the data and/or maintains them at locationsin the memory system of the computer, which reconfigures and/orotherwise alters the operation of the computer in a manner understood bythose skilled in the art. The data structures in which data ismaintained are physical locations of the memory that have particularproperties defined by the format of the data. However, while anembodiment is being described in the foregoing context, it is not meantto provide architectural limitations to the manner in which differentembodiments can be implemented. The different illustrative embodimentscan be implemented in a system including components in addition to or inplace of those illustrated for the determination system 100. Othercomponents shown in FIG. 1 can be varied from the illustrative examplesshown. The different embodiments can be implemented using any hardwaredevice or system capable of running program code. In anotherillustrative example, determination system 100 can take the form of ahardware unit that has circuits that are manufactured or configured fora particular use. This type of hardware can perform operations withoutneeding program code to be loaded into a memory from a computer readablestorage device to be configured to perform the operations.

For example, mobile device 105 can take the form of a circuit system, anapplication specific integrated circuit (ASIC), a programmable logicdevice, or some other suitable type of hardware configured to perform anumber of operations. With a programmable logic device, the device isconfigured to perform any number of operations. The device can bereconfigured at a later time or can be permanently configured to performany number of operations. Examples of programmable logic devicesinclude, for example, a programmable logic array, programmable arraylogic, a field programmable logic array, a field programmable gatearray, and other suitable hardware devices. With this type ofimplementation, software modules 130 can be omitted because theprocesses for the different embodiments are implemented in a hardwareunit.

In still another illustrative example, determination system 100 and/ormobile device 105 can be implemented using a combination of processorsfound in computers and hardware units. Processor 110 can have a numberof hardware units and a number of processors that are configured toexecute software modules 130. In this example, some of the processorscan be implemented in the number of hardware units, while otherprocessors can be implemented in the number of processors.

In another example, a bus system can be implemented and can be comprisedof one or more buses, such as a system bus or an input/output bus. Ofcourse, the bus system may be implemented using any suitable type ofarchitecture that provides for a transfer of data between differentcomponents or devices attached to the bus system. Additionally,communications interface 150 can include one or more devices used totransmit and receive data, such as a modem or a network adapter.

Embodiments and/or arrangements can be described in a general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, etc., that performparticular tasks or implement particular abstract data types.

The operation of the determination system 100 and the various elementsand components described above will be further appreciated withreference to the method for determining an in-vehicle role of a user ofa mobile device as described below, in conjunction with FIGS. 2A-2C.

Turning now to FIG. 2A, a flow diagram is described showing a routine201 that illustrates a broad aspect of a method for determining anin-vehicle role of a user of a mobile device 105 in accordance with atleast one embodiment disclosed herein. It should be appreciated thatseveral of the logical operations described herein are implemented (1)as a sequence of computer implemented acts or program modules running ondetermination system 100 and/or (2) as interconnected machine logiccircuits or circuit modules within the determination system 100. Theimplementation is a matter of choice dependent on the requirements ofthe device (e.g., size, energy, consumption, performance, etc.).Accordingly, the logical operations described herein are referred tovariously as operations, structural devices, acts, or modules. Variousof these operations, structural devices, acts and modules can beimplemented in software, in firmware, in special purpose digital logic,and any combination thereof. It should also be appreciated that more orfewer operations can be performed than shown in the figures anddescribed herein. These operations can also be performed in a differentorder than those described herein.

The process begins at step 210 where processor 110 executing one or moreof software modules 130, including, preferably, determination module170, receives a first input, such as from one or more of sensors 145,software modules 130, user interface 172, operating system 176, and/orcommunication interface 150. Preferably, the first input originates fromone or more identifying events that are perceptible to at least one ofsensors 145, user interface 172, operating system 176, and/orcommunication interface 150. Examples of such an input include, but arenot limited to, an acceleration input that originates from anacceleration event (e.g., the speeding up or slowing down of a car) thatis perceived by accelerometer 145A, a change in geographic locationinput that originates from a location changing event (e.g., the movementfrom one place to another) that is perceived by GPS receiver 145C,and/or one or more instances or user interaction (e.g., typing) that aredetected by user interface 172.

Then, at step 220, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, analyzesat least the first input, such as to identify one or more determinationcharacteristics within the first input, including but not limited touser determination characteristics. As will be described in greaterdetail below, user determination characteristics are one or more aspectsoriginating at and/or derived from an input that provide insightregarding the in-vehicle role and/or identity of the user that isexerting control over and/or otherwise associated with a mobile device,such as mobile device 105. For example, where the first input (receivedat step 210) is the typing of one or more letters into user interface172 (such as to compose a SMS message), determination module 170 cananalyze the typing to identify one or more user determinationcharacteristics (that is, characteristics that contribute to adetermination of the identity of the particular user that is associatedwith mobile device 105, as will be described below). In this case,determination module 170 can analyze the typing patterns within thefirst input (such as the time interval in between the typing ofindividual letters in the SMS message, the average time interval inbetween the typing of individual letters in the SMS message, and/or thevariability among one or more time intervals between the typing ofindividual letters in the SMS message). If there are substantial timeintervals in between the typing of various letters, and/or if the timeintervals in between typed letters vary widely, these factors canindicate that the user of mobile device 105 is likely distracted andthus unable to type consistently. Additional examples of analyzing aninput to identify one or more determination characteristics are providedbelow in EXAMPLE 1.

Upon identifying one or more determination characteristics, such as userdetermination characteristics, based on the analysis of an input, atstep 230 the processor 110 executing one or more of software modules130, including, preferably, determination module 170, computes one ormore determination factors (that is, factors that reflect and/or suggestone or more determinations that can be arrived at with respect to one ormore of the mobile device, its location, the user, and/or the vehicle).By way of example, a probability can be computed, based on the userdetermination characteristics, that the in-vehicle role of the user ofmobile device 105 is a driver and/or that the in-vehicle role of theuser of the mobile device 105 is a passenger. That is, in certainarrangements the user determination characteristics identified at step220 can provide varying degrees of certitude as to the identity or roleof a user. So, continuing the example provided with regard to step 220,while, on the one hand, significant time intervals between typed letterscan indicate that the in-vehicle role of the user is a driver, on theother hand if the time intervals in between the various letters are, onaverage, consistent and/or substantially similar this can indicate thatthe user is not necessarily distracted (due to being a driver), butrather is a passenger and is simply not adept at typing. Accordingly, insuch a case, in one arrangement the computed probability for such userdetermination characteristic(s) is preferably a lesser degree ofcertainty that the user is a driver (and/or a passenger), accounting forthe potentially conflicting indications from the various userdetermination characteristics. By way of further example, when the userdetermination characteristics indicate that a lesser degree of typinginconsistency and/or shorter intra-character time intervals exists,processor 110 executing software modules 130 preferably computes aprobability that the in-vehicle role of the user of mobile device 105 isa passenger. Similarly, when a greater degree of typing inconsistencyand/or longer intra-character time intervals exists, processor 110executing software modules 130 preferably computes a probability thatthe in-vehicle role of the user of mobile device 105 is a driver (beingthat the user determination characteristics appear consistent with theactivity of a driver within a vehicle). It should be appreciated thatbecause ranges exist for a particular user determination characteristic(such as typing consistency), a probability of an in-vehicle role ispreferably computed, reflecting a degree of certainty that the user ofmobile device is a driver and/or that the user of mobile device is apassenger.

Then, at step 240, the processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, transformsan operation state of the mobile device 105 based on the determinationfactors (such as the probability computed at step 230), and/or outputsat least one operation state based on the at least one determinationfactor, and/or outputs at least one in-vehicle role of the user based onat least one determination factor, and/or outputs at least onein-vehicle location of the mobile device 105 based on at least onedetermination factor, and/or outputs at least one result based on the atleast one determination factor. Various of these operations will bedescribed in greater detail herein. For example, if the computedprobability indicates that the in-vehicle role of a user of mobiledevice 105 is likely to be a driver, processor 110 can coordinate thedisabling of one or more features of the mobile device 105, such as thedisabling of any and/or all features that enable the entry of text intomobile device 105. In doing so, existing safety risks can be reduced bypreventing a user who has been determined to be likely to be a driver ofa vehicle from using various regular functions of mobile device 105 thatare likely to distract the user and increase safety risks while drivingand/or are restricted and/or prohibited based on the vehicle's current(or most recently known) location, as preferably determined inconjunction with GPS 145C. In other arrangements, one or more othertransformations to the operation state of mobile device can be similarlyapplied based on the computed probability. For example, notifications(such as warning notifications) can be provided at the mobile device105, notifications can be transmitted to third parties (notifying athird party, such as a law enforcement agency, of the in-vehicle role ofthe user of mobile device 105 and/or of the particular operation of themobile device 105, such as that typing is being performed upon mobiledevice 105), instructions can be provided to third parties (such as acellular service provider) to change an operation state of mobile device105 (such as temporarily disabling the communication ability of mobiledevice 105), and/or one or more applications executing or executable onmobile device 105 can be disabled (such as a text messagingapplication).

At this juncture, it can be appreciated that the operationscorresponding to transforming step 240 can be customized and/orconfigured in relation to various probabilities computed at step 230.That is, certain transformations of the operation state of mobile device105 (for example, notifying law enforcement authorities) may only beappropriate when there is a high probability (such as greater than 90%)that the in-vehicle role of a user of mobile device 105 is a driver (andfurther that the driver is interacting with mobile device 105 in anillegal manner while driving), while other transformations may beappropriate even for lower degrees of probability (for example, it maybe appropriate to provide a warning notification at mobile device 105even for a 60% probability that the user is a driver). Yet othertransformations can be employed preemptively, wherein the transformationis applied even before a prohibited interaction (e.g., typing into anSMS program) occurs, thereby avoiding restricted or prohibitedinteraction with mobile device 105, even at the first instance.Furthermore, as referenced above, in certain arrangements the user canconfigure how (that is, the type of transformation) and when (that is,the probability threshold that must be met in order to trigger thetransformation) the operation of mobile device 105 is to be transformed.In other arrangements, a third party can establish such configurations.For example, a regulatory agency can dictate that one or moretransformations be employed on some or all mobile devices when aparticular probability threshold that a user of the device is a driveris met. By way of further example, a car insurance provider can provideincentives to its customers who utilize one or more transformationsand/or probability thresholds suggested and/or dictated by the insurancecompany.

Turning now to FIG. 2B, a flow diagram is described showing a routine202 that illustrates a further aspect of a method for determining anin-vehicle role of a user of a mobile device 105 in accordance with atleast one embodiment disclosed herein. Though already noted above, itshould be particularly appreciated with reference to FIG. 2B that moreor fewer operations can be performed than shown in the figures anddescribed herein, and that these operations can be performed in adifferent order than those described herein. Thus, in certainarrangements certain of the operations of FIG. 2B can be performed whileothers are not, and further that in certain arrangements can beperformed in a sequence other than that depicted in FIG. 2B.

The process begins at step 210 where a first input of a first device 105is received, and proceeds to step 220 where the first input is analyzed.Steps 210 and 220 have already been described above with reference toFIG. 2A and thus will not be further elaborated upon here as theiroperation is substantially identical to steps 210 and 220 describedabove.

Then, at step 221, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, receives asecond input from one or more of sensors 145, software modules 130, userinterface 172, operating system 176, and/or communication interface 150.As described above with reference to step 210, examples of such an inputinclude, but are not limited to, an input corresponding to anacceleration perceived by accelerometer 145A, and/or an inputcorresponding to a change in geographic location as perceived by GPSreceiver 145C.

At step 222, the second input is analyzed by processor 110 executingdetermination module 170, in a manner substantially similar to thatdescribed above with reference to step 220, in order to identify one ormore determination characteristics such as user determinationcharacteristics within the second input. For example, where the secondinput (received at step 221) comprises one or more accelerationsdetected by accelerometer 145A, determination module 170 can analyze theaccelerations to identify one or more user determination characteristicswithin the second input. Here, determination module 170 can analyzevarious patterns within the second input (such as the time and durationof acceleration and deceleration). Certain patterns, such as frequentperiods of sustained forward acceleration interspersed with periodicintervals of rapid and/or brief forward deceleration can indicate thatthe user of mobile device 105 is likely traveling in, if not operating,a car which often follows such an acceleration/deceleration pattern. Asdescribed in detail herein, by identifying one or more userdetermination characteristics (such as identifying that the user ofmobile device 105 is likely traveling in a car, as described above), thecontext and significance of one or more other user determinationcharacteristics can be better evaluated and/or quantified. For example,the typing patterns of a user determined to be traveling in a moving carare, on average, of greater significance in determining whether the userof the device is a driver/passenger. On the other hand, the typingpatterns of a user of a mobile device 105 that has been determined notto be traveling in a moving car can be understood to be, on average, oflesser significance in determining whether the user of the device is adriver/passenger.

Then, at step 223, the processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, cancompare the determination characteristics such as user determinationcharacteristics identified within the first input (such as thoseidentified at step 220) with the determination characteristics such asuser determination characteristics identified within the second input(such as those identified at step 222). In doing so, one or morepatterns, correlations and/or relationships can be identified betweenthe user determinations characteristics of the first input and the userdetermination characteristics of the second input. By way ofillustration, referring to the examples discussed above, the typingpatterns identified at step 220 can be compared with theacceleration/deceleration patterns identified at step 222. In doing so,patterns, correlations, and/or relationships between the typing patternsand acceleration/deceleration patterns can be identified. For example,if time intervals between typed characters and/or typing inconsistenciesincrease at the same time as substantial and/or sudden forward and/orlateral acceleration and/or deceleration, this can further indicate thatthe user of a mobile device 105 is a driver. Being that for a driver toengage in a maneuver with sudden acceleration and/or deceleration thedriver is expected to have temporarily stopped typing due to theincreased attention a driver must pay to his driving activities, if suchaccelerations correlate closely with inconsistent typing speeds and/orslower typing speed and/or such accelerations are just prior to typingdelays, this can be a strong indication that the user of mobile device105 is a driver.

Additional illustrations of scenarios and/or arrangements whereinmultiple inputs are analyzed, compared, correlated, and/or processed inorder to determine various aspects of the roles of one or more users ofa mobile device 105, are provided throughout the present disclosure.

At step 224, the processor 110 executing one or more of software modules130, including, preferably, determination module 170, comparesdetermination characteristics such as user determination characteristics(including, but not limited to, the user determination characteristicsfrom the first input, as identified at step 220, and/or the userdetermination characteristics from the second input, as identified atstep 222) with stored determination characteristics such as userdetermination characteristics, such as those stored at one or moredatabases, such as database 174 (that is local to mobile device 105)and/or database/server 162 (that is external to mobile device 105).Stored user determination characteristics can be archived userdetermination characteristics that have been retained from previous userdeterminations that have been performed, can be generated based onstatistical analyses of previous user determinations, and/or can bedefined or established independent of any particular previous userdetermination. In comparing user determination characteristics (such asthose identified at step 220 and/or step 222) with stored userdetermination characteristics (such as stored user determinationcharacteristics that have historically demonstrated a high degree ofprediction accuracy in determining an in-vehicle role of a user), theprocessor 110 can more accurately compute the probability that thein-vehicle role of the user of mobile device 105 is a driver or that thein-vehicle role of the user of mobile device 105 is a passenger. Forinstance, following the example referenced above with regard to typinginconsistencies, if certain typing patterns have historically beendemonstrated as very reliable in determining the in-vehicle role, of theuser, various identified user determination characteristics (such asthose identified at step 220 and/or step 222) can be compared to suchstored determination characteristics (e.g., highly predictive typingpatterns). If the identified determination characteristics closelycorrelate to highly reliable/predictive stored determinationcharacteristics, the identified determination characteristics can besimilarly considered highly reliable and this correlation can furtherenhance the reliability of the computation of a probability regardingthe in-vehicle role of a particular user. Additional examples andillustrations of such comparisons are provided below at EXAMPLE 1.

At step 225, processor 110 executing one or more of software modules130, including, preferably, determination module 170, receives an inputfrom another device, such as one of mobile devices 160. It should beunderstood that the input received from mobile device 160 is preferablyfrom among the various types of inputs referenced above at steps 210 and221 (for example, an acceleration input that originates from anacceleration event that is perceived by accelerometer 145A, and/or achange in geographic location input that originates from a locationchanging event that is perceived by GPS receiver 145C), and thus willnot be described at length here. However, it should be appreciated thatthis input originates at mobile device 160 (that is, a device externalto mobile device 105), and thus the input from mobile device 160 ispreferably received by mobile device 105 through communication interface150.

Then, at step 226, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, processesan input of mobile device 105 against an input of one or more mobiledevices 160. In doing so, one or more determination characteristics suchas user determination characteristics can be identified within the inputof the first mobile device 105. By way of example, various typingpatterns and/or tendencies (referenced above) of mobile device 160 canbe processed against similar typing patterns/tendencies of mobile device105 (or, alternatively, various typing patterns and/or tendencies ofmobile device 105 can be processed against similar typingpatterns/tendencies of mobile device 160). In doing so, processor 110can analyze and/or identify the degree to which the input from mobiledevice 105 deviates from the input received from mobile device(s) 160,in a manner similar to the comparison discussed above at step 224(except that here the input of mobile device 105 is being processedagainst an input received from another mobile device 160, as opposed tocomparing one user determination characteristic with storedcharacteristics). Thus, continuing with the provided example, in a casewhere the typing tendencies of mobile device 105 are relativelyinconsistent, if, when processing the typing tendencies received frommobile device(s) 160 against those of mobile device 105 it is revealedthat the typing across many or all of the devices 105 and 160 issimilarly inconsistent, this can indicate that it there is notnecessarily a high probability that the user of mobile device 105 is adriver, despite the inconsistent typing inputs received at the device105 (rather, such inconsistent typing may be the result of the variousdevices 105 and 160 traveling along an off-road or bumpy road, whichwould make consistent typing difficult, even for passengers in avehicle). Additionally, if the typing tendencies of mobile device 105are relatively consistent, however when processing such input(s) againstinputs from mobile device(s) 160 it is revealed that the typingtendencies of the user of mobile device 105 are actually relativelyinconsistent, this can indicate a higher probability that the user ofmobile device 105 is a driver of a vehicle (even though the input frommobile device 105, in-and-of-itself, may not have generated the sameconclusion).

It should be noted that various limitations and/or filters can beimposed upon the receiving at step 225 and/or the processing at step226, to ensure the most accurate results possible. That is, while incertain arrangements it can be beneficial to receive inputs frompractically any mobile device 160 that is capable of communication withmobile device 105, in other arrangements it can be preferably to limitthe number of devices and/or inputs that are received by mobile device105 on the basis of one or more factors to ensure that the inputs beingreceived by mobile device 105 from such external devices 160 are thosethat can be expected to be of greatest relevance. Examples of factorsthat can be considered in imposing such limitations and/or filtersinclude proximity to mobile device 105 and/or similarity/compatibilitywith mobile device 105. To illustrate, in processing the typingtendencies of device 105 against those of another device 160, it can bepreferable to ensure that device 160 is in close proximity to mobiledevice 105 (such as through a comparison of the location coordinatesobtained from their respective GPS receivers or by causing one or moreof the mobile devices to emit one or more tones and/or signals (e.g., anaudio tone) that can then be received on other mobile devices that arein close proximity, as described in detail in EXAMPLE 2), therebyestablishing a high likelihood that mobile device 105 and mobile device160 are operating within the same vehicle (and are thus subjected tosubstantially identical conditions). To further illustrate, being thatvarious mobile devices such as smartphones utilize different userinterfaces and button configurations, it can be advantageous in certainarrangements to compare inputs from one mobile device 105 with those ofanother mobile device 160 that is either identical to or at least highlycompatible with mobile device 105 (such as a device using the sameoperating system). Due to differences across various mobile devices andoperating systems, ensuring that mobile device 105 and mobile device(s)160 are similar (if not identical) ensures that the inputs received fromeach can be assumed to be highly comparable.

Additional examples of processing inputs from one device 105, 160against those of one or more other devices to identify one or moredetermination characteristics are provided below in EXAMPLE 2.

In addition, in certain arrangements it is preferable that the inputsfrom mobile device 105 and those of mobile device 160 that are to beprocessed against one another/compared are substantially synchronizedfrom a chronological standpoint. That is, it is preferable that each ofthe various inputs be associated with a particular time (and that thesource of such time be a central clock, such as a server, which cansynchronize the various devices, though it should be understood that inother arrangements one or more of devices 105, 160 can broadcast timingdata that enables the calibration of the various devices), therebyenabling the processing of inputs from mobile device 105 with inputsfrom mobile device 160 that correspond to the same point in time. Doingso ensures that the various inputs being processed/compared are highlycomparable, in that they reflect the operations of the various devices105 and 160 in response to the same events (e.g.,accelerating/decelerating over the course of a driver). Additionalexamples and illustrations of such further processing operations areprovided below in EXAMPLE 3.

At step 227, processor 110 executing one or more of software modules130, including, preferably, determination module 170, receives an inputfrom vehicle data system 164, such as an on board diagnostic (OBD)computer or computing device (e.g., OBD-I, OBD-II, ECU, roll system,airbag system, and/or an ABS), preferably through communicationinterface 150. As noted above, vehicle data system 164 preferablyprovides data and/or information originating at the vehicle itself. Forexample, vehicle data system 164 can provide one or more inputs thatreflect various actions or events, such as a car's acceleration and/ordeceleration, steering, braking, and/or any other such car-relatedoperations. Such inputs can provide further insight into determining thein-vehicle role of a user of mobile device 105, as will be describedbelow.

Then, at step 228, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, processesan input of mobile device 105 against an input of vehicle data system164, in a manner similar to that described above with respect to step226. However, here an input of mobile device 105, such as various typingtendencies (as illustrated above) is processed against an input fromvehicle data system 164 that preferably pertains to an operation of acar (e.g., the car accelerating, braking, and/or swerving) and which isqualitatively different than the input of mobile device 105 becausevehicle data system 164 cannot necessarily detect the various stimuliperceptible to mobile device 105, owing in part to the fact that mobiledevice 105 is preferably not fixed relative to the car's coordinatesystem. As such, the various inputs (that is, the inputs from mobiledevice 105 and those from vehicle data system 164) are compared and/orsynchronized from a chronological standpoint, substantially in themanner described above with respect to step 226. In doing so, inputsfrom mobile device 105 can be processed against inputs from vehicle datasystem 164 (which, in turn, originate at the car itself), therebyenabling the association of various inputs from mobile device 105 withevents such as the accelerating, braking, and/or swerving of the car.Thus, following the typing tendencies example provided, if certainhighly erratic typing tendencies perceived at mobile device 160, occurjust prior and/or closely correlate to various driving operations(reflected in the inputs from vehicle data system 164) such asaccelerating, braking, and/or swerving, one or more user determinationcharacteristics can be identified with regard to the input(s) frommobile device 105, indicating that there is a high likelihood that thein-vehicle role of the user of mobile device 105 is a driver.

At this juncture, it can be appreciated that although several sectionsof the forgoing disclosure have referenced the processing and/orcomparison of various inputs against one another in context of inputsthat are qualitatively comparable (such as at steps 224 and 226, above,referring to the comparison of typing tendencies from various sources),in other arrangements various inputs that are not necessarilyqualitatively comparable (or, at least, do not appear to bequalitatively comparable). For example, in a manner similar to thatdescribed above with respect to step 223, an input of typing tendenciesfrom one source (such as mobile device 105) can be comparedwith/analyzed against an input of accelerations/decelerationsoriginating at mobile device 160. The respective inputs preferably havea timestamp to enable the chronological comparison between the inputs,as described in greater detail above with respect to step 226.

At step 230, processor 110 executing one or more of software modules130, including, preferably, determination module 170, computes one ormore determination factors, such as a probability, based on the variousdetermination characteristics, that the in-vehicle role of the user ofmobile device 105 is a driver and/or a probability that the in-vehiclerole of the user of the mobile device 105 is a passenger, substantiallyin the manner described in detail above with regard to step 230. Then,at step 240, the processor 110 executing one or more of software modules130, including, preferably, determination module 170, transforms anoperation state of the mobile device 105 and/or outputs at least oneoperation state based on the at least one determination factor, and/oroutputs at least one in-vehicle role of the user based on at least onedetermination factor, and/or outputs at least one in-vehicle location ofthe mobile device 105 based on at least one determination factor, and/oroutputs at least one result based on the at least one determinationfactor, as also described in detail above.

Turning now to FIG. 2C, a flow diagram is described showing a routine203 that illustrates a further aspect of a method for determining anin-vehicle role of a user of a mobile device 105 in accordance with atleast one embodiment disclosed herein. The process begins at step 210where an input is received from mobile device 105, and proceeds to step220 where the first input is analyzed. At step 230, a determinationfactor such as a probability is computed, based on the variousdetermination characteristics, as referenced above. Steps 210, 220, and230 have already been described above with reference to FIG. 2A and thuswill not be further elaborated upon here as their operation issubstantially identical to steps 210, 220, and 230 described above.

Then, at step 250, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, outputsone or more results based on the determination factor(s) computed atstep 230. Such results can include, but are not limited to, one or morefiles, notifications, and/or communications that contain and/or reflectoperations of the mobile device 105, and/or one or more operation statesof the first mobile device 105, and the outputting of such results canbe dependent upon a certain probability threshold, as described indetail herein. For example, in a scenario where mobile device 105 isconfigured to output results (such as that the in-vehicle role of a useris a driver/passenger) when the probability (that is, the reliability)of such results are greater than 75%, when mobile device 105 determineswith a probability of 80% that the in-vehicle role of a user of mobiledevice 105 is a driver, a corresponding notification can be outputtedreflecting such results. Thus, it can be appreciated that the referencedresults can be output based on the calculated probability that the userof mobile device 105 is a driver or that the user of mobile device 105is a passenger. It should be understood that the outputting referencedat this step can be employed in a number of ways depending on theparticular arrangement. For example, in certain arrangements thereferenced results can be transmitted to an external device orthird-party, such as a law enforcement agency, insurance company, and/orother device 160 (for example, a parent receiving results from a child'sdevice 105), via communication interface 150. It can be appreciatedthat, as referenced above with regard to step 240, the outputting ofsuch results to a law enforcement agency, insurance company, and/oranother device 160 can ensure that such entities are notified of thevarious operations and/or operation states of a particular mobile device105, especially when it has been determined that it is highly probablethat device 105 is being operated by a driver of a car. In anotherarrangement, such results can be outputted to mobile device 105 itselfin any number of ways, such as by logging the operations and/oroperation state(s) of mobile device 105 at times/intervals when it hasbeen determined, for instance, that there is a high probability that theuser of mobile device 105 is a driver. Irrespective of whether theresults are output to a third-party or to the device 105 itself, itshould be appreciated that the outputting of such results can provideinsight regarding the operations of the mobile device 105 at aparticular moment and/or interval, which can be utilized later, such asin investigating car crashes. For example, if a car crash occurs, alaw-enforcement agency can review such outputted results to determinewhether the driver was engaged in various distracting activities duringand/or near the time of the crash (e.g., mobile device 105 was beingused by driver with 93% certainty, was being used in a hand-held statewith 94% certainty, and was being used for texting with 100% certaintyat least 30 seconds prior to the crash). As such, it can be furtherappreciated in certain arrangements the various referenced results canbe outputted across any and/or all degrees of probability, therebyensuring a comprehensive log of a user results, reflecting the variousoperations and/or operation states throughout the course of operation ofthe mobile device 105.

In certain implementations, a device can be determined to be operated bya driver or a passenger based on one or more applications running at thedevice (and/or that are installed on the device but not necessarilyrunning). FIG. 43 is a flow diagram of a routine that illustratesaspects of one or more methods, such as those described in relation toone or more embodiments described herein. In various implementations,one or more aspects of the referenced method can be performed by one ormore hardware devices/components (such as those depicted in FIG. 1), oneor more software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4305 one or more operational aspects ofa user device can be identified. In certain implementations the one ormore operational aspects can include one or more applications executingat the mobile device. Moreover, in certain implementations the one ormore operational aspects can include one or more resources beingutilized at the mobile device. At 4310 the one or more operationalaspects can be processed, such as in order to determine one or morecharacteristics of a user of the user device. At 4315, one or moreoperations can be initiated, such as based on the one or morecharacteristics.

For example, a device determined to be within a moving vehicle that isrunning a ‘SatNav’ application can be determined to be relatively morelikely to be operated by a driver than by a passenger. Moreover, basedon the resources that the device is using (e.g., whether Bluetooth ispaired on the device), it can be determined that it is more likely thata driver is operating the device, while if a headset is plugged into thedevice's headset jack and music is playing while the device isdetermined to be within a moving vehicle, it is more likely that apassenger is operating the device.

Turning now to FIG. 3, a flow diagram is described showing a routine 300that illustrates an aspect of a method for enabling, disabling and/ormodifying at least a feature of a mobile device 105 in accordance withat least one embodiment disclosed herein.

The process begins at step 310 where processor 110 executing one or moreof software modules 130, including, preferably, determination module170, monitors one or more inputs from one or more of sensors 145,software modules 130, user interface 172, operating system 176, and/orcommunication interface 150. As described in detail above with referenceto step 210, examples of such inputs include, but are not limited to, anacceleration input, a geographic location input, and/or one or moreinstances or user interaction (e.g., typing).

Then, at step 320, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170 defines anoperation signature based on the inputs monitored at step 310. Thedefined operation signature preferably reflects a normal operation stateand/or a range of normal operation states of the mobile device 105. Thatis, based on the various inputs monitored at mobile device 105, over adefined time interval (for example, a day, a week, and/or a month) anoperation signature or profile can be defined that reflects one or morevalues or ranges of values that have been identified as the normal orregular operation of the device 105, the normal or regular usage of thedevice 105 by a particular user, and/or the normal or regular usage ofdevice 105 and/or a series or class of such devices by a particular userand/or a series or range of users. For example, after monitoring inputsfrom the accelerometer 145A of mobile device 105 for a period of time, arange of normal acceleration inputs of the device 105 can be determined.Similarly, upon monitoring inputs from the user interface 172 of mobiledevice 105, a range of normal typing tendencies (e.g., typing speeds,typing consistency, etc., as described herein) can be determined. Thesevarious inputs can be used to define an operation signature for themobile device 105 that reflects the normal operation and/or operatingrange of the device 105. It should be appreciated that the referencedoperation signature is not limited to a single input or type of input,but rather in certain arrangements can be made up of signatures of twoor more types of inputs. For example, in one arrangement a normaloperation signature can be made up of a range normal accelerometerinputs together with a range of normal typing tendencies.

At step 330, processor 110 executing one or more of software modules130, including, preferably, determination module 170, further monitorsone or more second inputs from one or more of sensors 145, softwaremodules 130, user interface 172, operating system 176, and/orcommunication interface 150, substantially in the manner described abovewith respect to step 310.

Then, at step 340, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, processesone or more of the second input(s) (monitored at step 330) against oneor more of the operation signature(s) (defined at step 320). In doingso, processor 110 executing one or more of software modules 130,including, preferably, determination module 170, can identify a degreeof deviation and/or a degree of correlation between the second input(s)and the operation signature(s). By way of example, various typingpatterns and/or tendencies (referenced above) of mobile device 105 canbe processed against an operation signature reflecting a range of normaltyping tendencies of mobile device 105, as referenced above with respectto step 320 and described in detail herein. In doing so, processor 110can analyze and/or identify the degree to which the one or more secondinput(s) (monitored at step 330) deviate from the operation signature ofmobile device 105 (defined at step 320). Thus, continuing with theprovided example, even in a case where the monitored typing tendenciesof mobile device 105 are not necessarily highly inconsistent, from anobjective standpoint, upon processing such inputs against an operationsignature (such as an operation signature reflecting that the typingtendencies of the user of mobile device 105 are generally highlyconsistent/accurate), it can be revealed that the monitored typingtendencies/inputs actually deviate substantially from the mobiledevice's 105 operation signature. In this example, such a deviation fromthe operation signature (which reflects the normal and/or expectedoperation of mobile device 105) can indicate that the mobile device 105is being operated under conditions that distract the user frominteracting normally with the device 105, such as during driving.Similarly, in an alternative example, in a case where the monitoredtyping tendencies of mobile device 105 are relatively inconsistent, froman objective standpoint, upon processing such inputs against anoperation signature (such as an operation signature reflecting that thetyping tendencies of the user of mobile device 105 are also generallyinconsistent, such as in the case of a new user who is not adept attyping), it can be revealed that the monitored typing tendencies/inputs(which otherwise reflect significantly inconsistent typing tendencies)actually correlate substantially with the mobile device's 105 operationsignature. In such an example, the correlation with the operationsignature (which reflects the normal and/or expected operation of mobiledevice 105) can indicate that the mobile device 105 is actually beingoperated under relatively normal/consistent conditions, and thus shouldnot be assumed to be operated under distracting conditions, such asdriving, as may have otherwise been concluded based on the inconsistenttyping tendencies alone.

At this juncture, it should be noted that steps 310 and 320 can berepeated on a periodic and/or constant basis, in order to further refinethe operation signature defined at step 320. That is, it can beappreciated that in certain scenarios a user's interaction with mobiledevice 105 can change and/or improve over time (such as in the case of anew user whose typing skills gradually improve with repeated use ofdevice 105), and thus the operation signature of mobile device 105should be adjusted, modified, and/or refined accordingly. It can beappreciated that this process can be achieved in any number of ways. Inone arrangement, mobile device 105 can be configured to periodicallyreset its operation signature (such as every month), such that onlyrecent operations are accounted for in defining the operation signature.In other arrangements, further inputs that are monitored can be factoredinto and/or averaged with previously monitored inputs, thereby updatingan existing operation signature. In yet other arrangements, furtherinputs can be factored into and/or averaged with previously monitoredinputs, and the more recent inputs can be weighted to place greateremphasis upon them, thereby updating an existing operation signaturewhile accounting for the fact that more recent inputs are of greatervalue in defining an accurate operation signature of a mobile device105.

At step 350, processor 110 executing one or more of software modules130, including, preferably, determination module 170, adjusts one ormore operations of mobile device 105. Preferably, this adjustmentcorresponds to the degree of deviation and/or the degree of correlationbetween one or more monitored inputs (such as the input monitored atstep 330) and one or more operation signature(s) of mobile device 105(such as the operation signature defined at step 320). It should beunderstood that in certain arrangements, this adjustment is similar tothe transformation of the operation state of mobile device 105 discussedin detail above with respect to step 240, and/or the outputting of oneor more results discussed in detail above with respect to step 250. Forexample, in certain arrangements, processor 110 can coordinate thedisabling of one or more features of the mobile device 105, such as thedisabling of any and/or all features that enable the entry of text intomobile device 105, while in other arrangements notifications (such aswarning notifications) can be provided at or transmitted to mobiledevice 105. Various other examples of adjustments to one or moreoperations of mobile device 105 are described in greater detail abovewith reference to steps 240 and 250.

As also described in detail above with respect to step 240, it should benoted that various of the adjustments employed at step 350 can becustomized and/or configured in relation to various degrees ofcorrelation and/or deviation identified at step 340. Thus, it can beappreciated that certain adjustments of the operation of mobile device105 (for example, notifying law enforcement authorities) may only beappropriate when a high degree of deviation from a normal operationstate (that is, from the operation signature) is identified (and,preferably, further that such a deviation is indicative of restricted orprohibited activity on the part of the user of mobile device 105). Otheradjustments, such as providing a notification at mobile device 105, maybe appropriate even for lower degrees of correlation/deviation, asdescribed in detail above.

In certain implementations, information regarding whether and how adevice user uses his/her device, such as when in a moving vehicle, canbe measured and/or recorded, whether or not the device user isdetermined to be the driver (or irrespective of a likelihood that thedevice user is the driver). Such technologies/techniques can be used,among other things, to log and analyze how large a “distracted driving”problem the device user has, i.e., based on how much and in what waysthe device's usage deviates from a particular device usage policy (e.g.,a state or federal law, a company policy, a parental policy, etc.) inconjunction with various determinations pertaining to the identity ofthe user (e.g., as a driver of a vehicle).

In certain implementations, such technologies can utilize informationobtained directly from the device (e.g., information about calls made orreceived, texts made or received, applications used, URLs visited,intermediate or final sources or destinations of data transmissions,device movement information, location information, network connectivityor visibility information, GPS, accelerometer, etc.) and/or informationobtained from third parties (e.g., mobile server providers, telematics,etc.).

The referenced information can also be saved to the device and/or to aremote server.

In certain implementations, the frequency or quantity (e.g., number ofscreen touches, number of key presses, time with screen on, CPUactivity, application switches, number of human or device spoken words)of device use is used as an indicator to determine vehicle role. Suchfrequency can be measured in various ways (e.g., (i) relative to others;(ii) relative to self (e.g., same device); (iii) relative to self asdriver; and (iv) relative to self as passenger) to make suchdetermination. For example, if a device user uses her device, onaverage, at least once every five (5) minutes (during waking hours)throughout the day and, for a period in which the device was in avehicle, she doesn't use it for 60 minutes, there is a relativelygreater likelihood that her in-vehicle role was that of a driver.Similarly, if a device user has, on average, 5 device interactions(e.g., key presses) per minute (during waking hours) throughout the dayand, for a period in which the device was in a vehicle, the quantity ofkey presses was 400 over 60 minutes, there is a relatively greaterlikelihood that her in-vehicle role was that of a passenger.

Turning now to FIG. 4, a flow diagram is described showing a routine 400that illustrates an aspect of a method of determining at least one of anin-vehicle role of a user of a first mobile device and/or a handheldstate of the first mobile device and/or a vehicle class of a vehiclecontaining the first mobile device using a central machine in accordancewith at least one embodiment disclosed herein. As will be described ingreater detail below, various of the steps and operations that make uproutine 400 share substantial similarities to those described above inconnection with FIGS. 2A-C and 3. However, it should be understood thatwhile FIGS. 2A-C and 3 principally concern determinations occurring atmobile device 105, routine 400 is primarily directed to determinationsperformed at central machine 168, as will be described in greater detailbelow. It should be further noted that, as described in greater detailbelow, while any one of the particular steps, operations, and/orfunctions are described throughout the present disclosure as beingperformed at and/or upon a particular machine or device (such as mobiledevice 105, mobile device 160, and/or central machine 168), suchdescription should be understood as being exemplary and/or illustrativeand not limiting. Accordingly, it can be appreciated that any and allsteps, operations, and/or functions described herein with regard to aparticular device and/or machine (such as central machine 168) should besimilarly understood to be similarly capably of employment at anotherdevice and/or machine (such as mobile device 105), substantially in themanner described herein, without departing from the scope of the presentdisclosure.

The process begins at step 410 where processor 4110 of central machine168 (depicted in FIG. 1) executing one or more of software modules 4130,including, preferably, determination module 4170, receives (preferablythrough communication interface 4150) a first notification from mobiledevice 105, the first notification preferably corresponding to an inputoriginating from one or more of sensors 145, software modules 130, userinterface 172, operating system 176, and/or communication interface 150of mobile device 105. As described in detail above with respect to step210, the first input originates from one or more identifying events thatare perceptible to at least one of sensors 145, user interface 172,operating system 176, and/or communication interface 150 of mobiledevice 105, such as an acceleration input perceived by accelerometer145A, a change in geographic location input perceived by GPS receiver145C, and/or one or more instances or user interaction (e.g., typing)detected by user interface 172. A notification, such as a computerreadable file containing information that reflects the input itself aswell as information that is pertinent to the input (such as the time,date, and a unique identifier such as a MAC address of mobile device105) is preferably generated by mobile device 105 based on the input,and is transmitted by communication interface 150 of mobile device 105to central machine 168, preferably via communications network 166. Asnoted above, it should be recognized that while FIG. 1 depicts centralmachine 168 communicating with mobile device 105 via network/Internet166, it should be understood that in other arrangements central machine168 communicates with mobile device 105 directly, such as through adirect Bluetooth pairing and/or through an ad-hoc wireless network.

Then, at step 420, processor 4110 of central machine 168 executing oneor more of software modules 4130, including, preferably, determinationmodule 4170, analyzes at least the first notification to identify one ormore determination characteristics, such as one or more of userdetermination characteristics and/or one or more handheld statecharacteristics and/or one or more vehicle determination characteristicswithin the notification. As described in detail above with respect tostep 220, user determination characteristics are one or more aspectsoriginating at and/or derived from one or more input(s) and/ornotification(s) that provide insight regarding the in-vehicle role,and/or identity of the user that is exerting control over and/orotherwise associated with a mobile device, such as mobile device 105.Similarly, handheld state characteristics are one or more aspectsoriginating at and/or derived from one or more input(s) and/ornotification(s) that provide insight regarding the handheld state of amobile device, such as mobile device 105, such as whether mobile device105 is being operated by a user in a handheld or non-handheld state (forexample, various angles and/or sudden changes perceived by gyroscope145B can indicate that mobile device 105 is being operated in a handheldstate by a user). It can thus be appreciated that while the underlyinganalysis performed at the present step 420 and at step 220, as describedabove, are substantially similar, here the analysis is performed bycentral machine 168 based on notifications received from mobile device105, while at step 220 the analysis is preferably performed by mobiledevice 105 itself. Having this analysis performed at central machine 168(as opposed to at mobile device 105, from which the notificationanalyzed at this step originates) provides several advantages in certainscenarios over having the analysis performed at mobile device 105, asdescribed at step 220. For example, the analysis performed at thepresent step can be quite resource intensive, and shifting this analysisto central machine 168 ensures that the system resources of mobiledevice 105 remain relatively free. Additionally, in certain arrangementscentral machine 168 can be operated by a law enforcement agency, and, assuch, a centralized approach, such as the one described with respect toFIG. 4, can provide such an agency with the ability to monitor and/oradjust the operational capacity of mobile device 105 as necessary, aswill be described in greater detail below. Moreover, in certainscenarios this centralized approach can be easier to implement withrespect to regulatory compliance and preventing tampering. It isexpected that both regulatory authorities who are interested inimplementing a solution such as that described with reference to FIG. 4are more likely to succeed in obtaining compliance from mobile devicemanufacturers and/or mobile communications providers when requiring asolution that primarily only requires, from the standpoint of the mobiledevice 105, periodic notification transmissions from mobile device 105to central machine 168. In addition, such a solution can be moredifficult for users to manipulate, modify, and/or ‘hack,’ given that theprimary analysis is performed by central machine 168, as opposed tomobile device 105.

At step 430, processor 4110 of central machine 168 executing one or moreof software modules 4130, including, preferably, determination module4170, computes one or more determination factor(s), such asprobabilities, based on the determination characteristics identified atstep 420. It should be understood that, for instance, based on theparticular inputs upon which a notification (which is analyzed at step420) is based, various user determination characteristics and/orhandheld state characteristics are generated. For example, as referencedabove, in certain arrangements user determination characteristics areidentified (such as typing tendencies, as referenced above), while inother arrangements handheld state characteristics (such as one or moreangles detected by mobile device 105, as referenced above) can beidentified, while in yet other arrangements both user determinationcharacteristics and handheld state characteristics can be identified. Inany event, at step 430, one or more probabilities are computed bycentral machine 168, reflecting a probability that the in-vehicle roleof the user of mobile device 105 is a driver, a probability that thein-vehicle role of the user of the mobile device 105 is a passenger, aprobability that the handheld state of the mobile device 105 ishandheld, and/or a probability that the handheld state of the mobiledevice 105 is non-handheld, all in a manner substantially similar tothat described in detail above with respect to step 230. It should beunderstood that, as described in detail above, in certain arrangementsthe user determination characteristics and/or handheld statecharacteristics identified at step 420 can provide varying degrees ofcertitude as to the identity/role of a user and/or the handheld state ofmobile device 105. Accordingly, it should be appreciated that becauseranges exist across the spectrum of a particular user determinationand/or handheld state characteristic (such as typing consistency and/ordevice angle), a probability that an in-vehicle role of the user ofmobile device 105 is a driver/passenger and/or a probability that ahandheld state of mobile device 105 is handheld/non-handheld preferablyreflects a degree of certainty across such a probability spectrum, asdescribed in detail above.

Then, at step 440, processor 4110 of central machine 168 executing oneor more of software modules 4130, including, preferably, determinationmodule 4170, adjusts an operational capacity of mobile device 105 basedon the one or more determination factor(s), such as at least one of theprobabilities computed at step 430, substantially in the mannerdescribed in detail above with respect to step 240. However, it shouldagain be understood that while the description pertaining to step 240above relates to adjustments and transformations initiated by mobiledevice 105 upon itself, here the adjustments to the operation of mobiledevice 105 are initiated by central machine 168. For example, in certainarrangements central machine 168 can transmit an operation command, suchas a command in the form of one or more notifications, messages, and/orinstructions that reflect various adjustments that are to be made to theoperational capacity of mobile device 105, and such adjustments can thenbe applied to mobile device 105 upon its receipt of the transmittedoperation command(s), and/or their application/execution, effectingsimilar and/or identical results as those described in detail above withrespect to step 240 (e.g., providing notifications at mobile device 105,restricting operation of mobile device 105, and/or transmittingnotifications from mobile device 105 to third parties). In otherarrangements, central machine 168 can adjust the operational capacity ofmobile device 105 based primarily and/or exclusively on adjustments madeat and/or by central machine 168 which, in turn, preferably effect orotherwise adjust the operational capacity of mobile device 105. Forinstance, in an arrangement where central machine 168 is controlled by amobile communications provider such as a cellular communicationsprovider, an adjustment can be implemented at central machine 168whereby one or more of the services provided by mobile communicationsprovider to mobile device 105 (such as phone, SMS, and/or data services)can be interrupted and/or otherwise adjusted or modified, therebyeffecting the operation of mobile device 105 through an adjustmentoccurring at central machine 168 based on the probability computed atstep 430. It should be noted that in other arrangements, substantiallysimilar adjustments can be implemented upon and/or through one or moreservice providers that provide one or more services, whether directly orindirectly, to mobile device 105. By way of illustration, various voiceover IP (VoIP) providers, such as Skype, enable users to achieve voicecommunications (akin to telephone calls) over data connections (such asan internet connection). By way of further illustrations, the ‘Viber’app enables similar SMS capabilities over an internet connection. In anyevent, it should be understood that the methods and systems disclosedherein can be configured such that any necessary adjustment can beimplemented upon and/or through the requisite service provider (forexample, by limiting the calling capabilities of Skype and/or the SMScapabilities of Viber) substantially in the manner described in detailabove.

At step 450, processor 4110 of central machine 168 executing one or moreof software modules 4130, including, preferably, determination module4170, outputs one or more results and/or operation states of mobiledevice 105 based on the one or more determination factor(s), such as theprobability or probabilities computed at step 430, substantially in thesame manner as described in detail above with respect to step 250. Butagain, as noted above, it should be understood that while thedescription provided above with respect to step 250 pertains to one ormore operations performed at mobile device 105, step 450 primarilypertains to operations initiated and/or performed by central machine168. Accordingly, it can be appreciated that the one or more operationstate(s) outputted by central machine 168 reflect the operation state(s)of mobile device 105 (for example, that the device is being used in ahandheld state and/or that the device is being used by a driver). Asnoted in detail above with respect to step 250, the outputting of theoperation state(s) can be further based upon one or more determinationfactor(s), such as one or more probabilities computed at step 430, whichreflects the likelihood or degree of certainty that a user of mobiledevice 105 is a driver/passenger and/or that mobile device 105 is beingused in a handheld/non-handheld state. As also noted in detail above, incertain arrangements the operation state of mobile device 105 can beoutputted by central machine 168 to an external device or third-party,such as a law enforcement agency, insurance company, and/or other device160, via communication interface 4150. Such functionality can beadvantageous in jurisdictions where administrative regulations recommendand/or require that entities such as mobile communications providersprovide information to law enforcement agencies that reflects theunauthorized usage of mobile devices such as mobile device 105 while theuser of the device is driving. Similarly, such functionality can beadvantageous to insurance companies when processing an insurance claim.Even in situations where the user of a mobile device, such as mobiledevice 105, is uncooperative in providing information to the insurancecompany, and/or in situations where the mobile device associated with aninvolved party is no longer available or has been destroyed, centralmachine 168 (which receives and retains the various pertinentnotifications/inputs provided by the various devices such as mobiledevice 105) can output the necessary data, such as the operation stateof mobile device 105, thereby assisting the insurance company to makenecessary decisions regarding the validity of a particular insuranceclaim.

Turning now to FIG. 5, a flow diagram is described showing a routine 500that illustrates an aspect of a method of determining a vehicle class ofa vehicle using a first mobile device in accordance with at least oneembodiment disclosed herein. As will be described in greater detailbelow, determining the vehicle class of a particular vehicle can providefurther insight and accuracy in the determination of an in-vehicle roleof a user of a mobile device. In addition, it should be understood thatthe various steps and/or operations that make up routine 500 sharesubstantial similarities to those described above in connection withFIGS. 2A-C and 3-4.

The process begins at step 510 where processor 110 executing one or moreof software modules 130, including, preferably, determination module170, receives a first input from one or more of sensors 145, softwaremodules 130, user interface 172, operating system 176, and/orcommunication interface 150.

Then, at step 520, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, analyzesat least the first input to identify one or more vehicle determinationcharacteristics within the first input. As will be described in greaterdetail below, vehicle determination characteristics are one or moreaspects originating at and/or derived from an input that provide insightregarding the vehicle class within or upon which and/or in relation tomobile device 105 is traveling.

Upon identifying one or more vehicle determination characteristics basedon the analysis of an input, at step 530 processor 110 executing one ormore of software modules 130, including, preferably, determinationmodule 170, computes at least one determination factor based on thevehicle determination characteristic(s), such as a probability that thevehicle corresponds to a particular vehicle class.

Then, at step 550, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, outputs avehicle class based on the one or more determination factor(s), such asthe probability or probabilities computed at step 530.

It should also be noted that, in certain arrangements, the processor 110executing one or more of software modules 130, including, preferably,determination module 170, can transform an operation state of mobiledevice 105 based in whole or in part on the determination factor(s),such as the probability computed at step 530. This operation can befurther appreciated when employed in conjunction with a determination ofan in-vehicle role of a user of mobile device 105, such as that depictedin FIGS. 2A-C and described in detail above. For example, in certainarrangements, upon determining (preferably to a certain minimumprobability) that a mobile device 105 is traveling within a certainclass of vehicle, there can be little need to further determine thein-vehicle role of the user of the device 105 (e.g., if the vehicle isan airplane, all device usage can be prohibited, irrespective of aparticular user's in-vehicle role). By way of further example, in otherarrangements, a transformation (substantially similar to that describedin detail above with respect to step 240) can be employed based uponboth the computed probability that mobile device 105 is traveling in acar, together with the computed probability (such as that described indetail above with respect to step 230) that the in-vehicle role of auser of mobile device 105 is a driver. In such a scenario, processor 110can coordinate various transformations and/or adjustments to theoperation(s) of mobile device 105, as described in detail above withrespect to step 240. As also noted above, in certain arrangementsvarious of the referenced transformations can be employed only wheneither one or both of the probabilities pertaining to the vehicle classwithin which mobile device 105 is traveling and/or the in-vehicle roleof the user of mobile device 105 is a driver meet and/or exceed acertain minimum threshold.

It can be appreciated that the physical properties of the interiors ofvehicles of different vehicle classes tend to be different from those ofother vehicle classes. Accordingly, in certain implementations, variousphysical properties (e.g., interior height, width, volume, varyingsignal absorption and reflections at different frequencies, etc.) ofdifferent vehicle classes (e.g., bus vs. car, train vs. car) can beprocessed/compared to determine the vehicle class that a mobile deviceis present within, together with and/or without various other vehicleclass determination techniques, such as those described herein and/orknown to those of ordinary skill in the art. For example, one or more ofa device's speakers can be used to emit one or more sounds (e.g., havinga certain frequency, length, volume, etc.) (and/or signals at otherfrequencies, e.g., RF) and one or more of the device's microphones canbe used to hear/perceive such sounds and/or the echoes thereof as thesounds emitted reflect off the objects and structure inside the vehicle(and whose flight time can be longer than the time it takes to travelfrom the device speaker to the device microphone).

For example, the time it takes for an echoed sound emitted by a device'sspeakers to be perceived by the device's microphones is relativelysmaller for cars (generally having a shorter distance to sides andceiling) than for buses (generally having a longer distance to sides andceilings) or the total energy of the echoes returned to the device willtend to be larger for cars than for trains because of their smallervolume. In another example, the sounds emitted are chosen to be onesthat tend to reflect better (or worse) off car interiors than off traininteriors so that, by measuring the time and/or energy of the echoesreturned, the vehicle class can be more accurately identified.

In another embodiment, the sound echoing technique described herein canalso be used to better determine whether a device is present within avehicle or whether a device (and/or its user) is present outside avehicle and/or engaged in another form of activity (with or without theuse of various other trip detection and/or activity recognitiontechniques, such as those described herein or known to those of ordinaryskill in the art).

In certain implementations, inputs originating from one or more motionsensors (e.g., accelerometer, gyroscope, etc.) of a device can beprocessed to determine the class of the vehicle within which the deviceis located (e.g., car, bus, train, etc.) and, based upon the determinedvehicle class, one or more restrictions (and/or no restrictions) can beemployed at/in relation to the device. For example, based on thedifference between the rates and lengths of acceleration of differentvehicle classes, it can be determined whether the pattern ofacceleration that can be perceived based on various inputs originatingfrom and/or determined with respect/in relation to a device (e.g.,accelerometer, GPS, cellular, WiFi) reflects that the device is presentwithin a train (e.g., the forward acceleration of a train is an order ofmagnitude lower than the forward acceleration of a car, while the lengthof sustained acceleration of a train is longer than that of a car), apolicy of no restrictions is applied to the device on the premise thatit is a passenger device (while different policies can be applied tothose few devices of users who are train conductors, bus drivers etc.).

Turning now to FIG. 6, a flow diagram is described showing a routine 600that illustrates an aspect of a method of determining a handheld state amobile device in accordance with at least one embodiment disclosedherein. As will be described in greater detail below, various of thesteps and operations that make up routine 600 share substantialsimilarities to those described above in connection with FIGS. 2A-C, 3,4, and 5. However, it should be understood that while at least FIG. 4principally concerns determinations occurring at central machine 168,routine 600 is primarily directed to determinations performed at mobiledevice 105, as will be described in greater detail below.

The process begins at step 610 where processor 110 executing one or moreof software modules 130, including, preferably, determination module170, receives a first input from one or more of sensors 145, softwaremodules 130, user interface 172, operating system 176, and/orcommunication interface 150. Preferably, the first input originates fromone or more identifying events that are perceptible to at least one ofsensors 145, user interface 172, operating system 176, and/orcommunication interface 150. As described in detail above with respectto step 210, the first input originates from one or more identifyingevents that are perceptible to at least one of sensors 145, userinterface 172, operating system 176, and/or communication interface 150of mobile device 105, such as an acceleration input perceived byaccelerometer 145A and/or a change in orientation input perceived bygyroscope 145B. It should be noted that in certain arrangements a seriesof inputs (such as a number of acceleration inputs over a certain periodof time) and/or a combination of inputs (such as a number ofacceleration inputs and orientation inputs over a period of time) arereceived, such as one or more inputs that reflect the incidence ofshaking or vibration at mobile device 105.

Then, at step 620, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, analyzesat least the first input to identify one or more handheld statecharacteristics within the notification. As described in detail abovewith respect to step 420, handheld state characteristics are one or moreaspects originating at and/or derived from one or more input(s) thatprovide insight regarding the handheld state of a mobile device, such asmobile device 105, such as whether mobile device 105 is being operatedby a user in a handheld or non-handheld state. For example, variousorientations and/or sudden changes perceived by gyroscope 145B(preferably, in certain scenarios, in combination with one or moreinputs from various other sensors 145 such as accelerometer 145A, GPS145C, and/or magnetometer 145E) can indicate that mobile device 105 isbeing operated in a handheld state by a user. By way of further example,a relatively constant pattern of inputs from accelerometer 145A and/orgyroscope 145B can indicate that mobile device 105 is positioned in arelatively stable manner, thus indicating that it is being operated in anon-handheld state.

At step 630, processor 110 executing one or more of software modules130, including, preferably, determination module 170, computes one ormore determination factor(s), based on the handheld state determinationcharacteristic(s), such as a probability that that the handheld state ofmobile device 105 is handheld, or that the handheld state of mobiledevice 105 is non-handheld. By way of example, based on a series ofaccelerometer 145A and gyroscope 145B inputs, the pattern of whichindicates ongoing vibration and/or movement, it can be computed thatthere is a high probability (e.g., greater than 90%) that mobile device105 is being operated in a handheld state. This is because a user ofhandheld mobile device 105—and particularly a driver who is furtherdistracted by his/her driving responsibilities—is liable to produce farmore vibration/shaking that is perceptible by mobile device 105,especially as compared to a non-handheld device that is stationed in adock, for instance. In any event, at step 630, such probabilities arecomputed, reflecting a probability that the handheld state of the mobiledevice 105 is handheld, and/or a probability that the handheld state ofthe mobile device 105 is non-handheld, in a manner substantially similarto that described in detail above with respect to steps 230 and 430. Itshould be understood that, as described in detail above, in certainarrangements the handheld state characteristics identified at step 620can provide varying degrees of certitude as to the handheld state ofmobile device 105. Accordingly, it should be appreciated that becauseranges exist of a particular handheld state characteristic (such asdevice shake patterns), a probability that a handheld state of mobiledevice 105 is handheld/non-handheld preferably reflects a degree ofcertainty across such a probability spectrum, as described in detailabove.

At step 650, processor 110 executing one or more of software modules130, including, preferably, determination module 170, outputs one ormore handheld states of mobile device 105 based on the one or moredetermination factor(s), such as the probability or probabilitiescomputed at step 630, substantially in the same manner as described indetail above with respect to steps 250, 450, and 550. For example, if,at step 630, it is computed that it is 90% likely that mobile device 105is being operated in a handheld state, at step 650 a notification can beprovided at mobile device 105 indicating that it has been determinedthat the device is being so operated. In certain arrangements such anotification can further include a suggestion/instruction that the userof the device 105 refrain from further use of the device, in deferenceto regulatory guidelines. In other arrangements, the handheld state ofmobile device 105 can be output to a third-party, such as a lawenforcement agency, under appropriate circumstances. Additionally, asnoted in detail above with respect to step 250, such outputting can, incertain arrangements, be contingent upon a certain minimum probabilitybeing computed (e.g., a 90% or greater probability that a mobile device105 is operating in a handheld state), while in other arrangements thehandheld state can be outputted across any and/or all degrees ofprobability.

Described herein in various implementations are techniques (includingmethods, systems, etc.) that are operative to improve the accuracy ofvarious determinations, including determinations pertaining to whether adevice is in a particular context (or not) and/or reducing the powerconsumed/expended (such as by the device) in order to make suchdetermination(s). Such techniques can be advantageous, for example, insituations in which such determinations are to be made repeatedly overextended periods of time. It should be understood that, in certainsituations, particular sources of information that may otherwise beconsidered/analyzed in order to make certain context-baseddeterminations/decisions may not be available. For example, in variousurban locations or in certain climatic conditions (e.g., duringcloudy/stormy weather) GPS information may not be available, and suchinputs are thus unavailable to be used in determining movement and/orspeed by/in relation to a device. It can also be appreciated that usageof such sensors can consume substantial amounts of power at the device.As such, it can be advantageous (such as in circumstances in which oneor more sensors/inputs are unavailable or unreliable) to employdetermination techniques that use different/alternative sources ofinformation (such as other sensors) in order to determine a context ofthe device.

FIG. 27 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 2705, one or more power chargingaspects can be determined, such as in relation to a user device. At2710, the one or more power charging aspects can be processed. In doingso, a context of the user device can be determined. At 2715 one or moreoperations can be initiated. In certain implementations, such operationscan be initiated based on the context. Moreover, in certainimplementations, such operations can be initiated in relation to theuser device.

FIG. 28 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 2805, one or more indications can bereceived. In certain implementations each of the one or more indicationscan correspond to a perception of one or more access points. Moreover,in certain implementations each of the one or more indications can beassociated with an operational context of a device. At 2810, the one ormore indications can be processed. In certain implementations, suchindications can be processed in order to determine one or morecharacteristics associated with one or more respective perceptions of atleast one of the one or more access points. At 2815, the one or morecharacteristics can be associated with one or more operational contexts.At 2820, one or more operations can be initiated. In certainimplementations, such operations can be initiated based on adetermination of at least one of the one or more characteristics inrelation to a user device. Moreover, in certain implementations suchoperations can be initiated in relation to the user device based on atleast one of the one or more operational contexts.

FIG. 29 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 2905, one or more operationalcharacteristics of a device can be identified. At 2910, one or morecontextual determination methods can be selectively employed, such as inrelation to the device. In certain implementations, such determinationscan be employed based on the operational characteristics. At 2915, aninapplicability of at least one of the one or more contextualdetermination methods can be determined, such as in relation to thedevice. In certain implementations such an inapplicability can bedetermined based on at least one of the operational characteristics.

FIG. 30 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3005 one or more indications can bereceived. In certain implementations, each of the one or moreindications can correspond to a perception of one or more access points,such as in relation to a user device. In certain implementations, atleast one of the one or more indications can include one or morelocations, such as those corresponding to the at least one of the one ormore access points. At 3010, the one or more indications can beprocessed, such as in relation to one or more access point records. Indoing so, one or more characteristics of at least one of the one or moreaccess points can be determined. In certain implementations, the one ormore characteristics can include (a) nomadic or (b) stationary. Incertain implementations, the one or more locations can be processed,such as in order to determine a locational variability, such as withrespect to the at least one of the one or more access points. In certainimplementations, the locational variability can include a differencebetween (a) a location associated with a connection to the at least oneof the one or more access points and (b) a location associated with adisconnection from the at least one of the one or more access points. At3015, a context of the user device can be determined. In certainimplementations, such a context can be determined based on the one ormore characteristics. In certain implementations, the context caninclude at least one of: (a) within a vehicle, (b) not within a vehicle,(c) within a trip, or (d) not within a trip. In certain implementations,it can be determined that the user device is at least one of (a) notwithin a vehicle or (b) not within a trip, such as based on adetermination that the user device perceived a stationary access pointthroughout a chronological period. In certain implementations, a contextof the user device can be determined, such as based on the locationalvariability.

FIG. 31 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3105 one or more indications can bereceived. In certain implementations, each of the one or moreindications can correspond to a perception of one or more access points,such as in relation to a user device. At 3110, the one or moreindications can be processed, such as in order to determine avariability with respect to the one or more indications. In certainimplementations, the variability can include a quantity of distinctaccess points perceived during a chronological period. At 3115, acontext of the user device can be determined, such as based on thevariability.

FIG. 32 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3205 one or more indications can bereceived. In certain implementations, each of the one or moreindications can correspond to a perception of one or more access points,such as in relation to a user device. At 3210, the one or moreindications can be processed, such as in order to determine a quantityof access points perceptible to the user device. At 3215, a context ofthe user device can be determined, such as based on the quantity. Incertain implementations, the context can include (a) an urban locationor (b) a rural location. At 3220, a trip determination threshold can beselected, such as with respect to the user device. In certainimplementations, the trip determination threshold can be selected basedon the context.

FIG. 44 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4405 one or more indications can bereceived, each of the one or more indications corresponding to aperception of one or more access points in relation to a user device. At4410, the one or more indications can be processed, such as to determineone or more characteristics of at least one of the one or more accesspoints. At 4415, a context of the user device can be determined, such asbased on the one or more characteristics. At 4420, one or morecharacteristics can be associated with one or more operational contexts.At 4425, one or more operations can be initiated, such as based on adetermination of at least one of the one or more characteristics inrelation to a user device. In certain implementations, the one or moreoperations can be initiated in relation to the user device based on atleast one of the one or more operational contexts. At 4430, a tripdetermination threshold can be selected with respect to the user device,such as based on a context.

FIG. 45 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4505 one or more inputs associated witha user device can be processed, such as to determine one or moremobility characteristics of the user device. At 4510, a context of theuser device can be determined, such as based on a determination that theone or more mobility characteristics comprise mobile operation and donot comprise operation consistent with walking.

FIG. 46 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4605 an indication can be received,corresponding to a perception of a nomadic access point in relation to auser device. At 4610, a quantity of devices with respect to which thenomadic access point is perceptible can be determined. At 4615, acontext of the user device can be determining, such as based on thequantity.

By way of illustration, various techniques described herein can pertainto determinations as to whether or not a device is present/operational‘within a vehicle’ (e.g., a moving vehicle) and/or ‘within a trip’(e.g., a trip within a moving vehicle) (it should be noted that suchterms can be used interchangeably). In doing so, various aspects of thepower consumed/expended by a device (such as in order to make one ormore of the referenced determinations) can be reduced. Moreover, one ormore of the referenced techniques can also be implemented to determineor otherwise detect other contexts while consuming/expending relativelyless power, e.g., determining the in-vehicle role of a user of aparticular device, whether or not a device is present within a class oron school grounds, what mode/class of transportation/vehicle the deviceis present within (e.g., car, train, bus, bicycle, walking, etc.),whether or not the user is a vulnerable road user, and more.

In one implementation, information related to one or more aspects of thebattery and/or the power consumption of a device (e.g., whether thedevice is connected to power, the voltage across the battery of thedevice, the charge level and/or the battery temperature level of thebattery of the device) and/or changes thereto over time (e.g.,variability), can be used to determine whether the device is in avehicle.

For example, being that device batteries are likely to charge relativelyless quickly when connected to power within a vehicle than suchbatteries charge when plugged into a wall outlet (in light of thegenerally lower amperage of car chargers as compared to wall chargers),a determination that the charge level of a battery that is connected topower is increasing relatively slowly can indicated an increasedlikelihood that the device is present within a vehicle.

Moreover, in certain implementations the referenced technique(s) canalso incorporate aspects relating to the power being consumed by thedevice (e.g., in order to operate). For example, with respect to adevice that is connected to a power source and whose battery level isincreasing relatively slowly and is not consuming/expending significantamounts of power (that might otherwise account for such a relativelyslow battery level increase, such as applications running, screen state,GPS, Bluetooth, Win etc., sensors sampled), it can be determined thatsuch a device is relatively likely to be present within a vehicle(rather than being connected to a wall outlet). In yet furtherimplementations, such technique(s) can further incorporate variouscomparisons and/or machine learning techniques with respect tocharacteristics pertaining to the battery of a device (e.g., in relationto the performance/operation of the specific battery and/or the specificdevice and/or across a population of identical and/or similar/comparablemodel batteries and/or devices over time).

In certain implementations a variability in the rate at which a batterycharges can be used to determine a context in which a device isoperating (e.g., within a vehicle). Such determinations can be madebased on the variability in the rate at which the battery of a devicecharges, as a device that is connected to a car charger is relativelymore likely to display a relatively more variable battery charge ratethan a device connected to a wall outlet.

In another implementation, one or more aspects of a context within whicha device is present/operating can be determined based on the voltageacross a battery of the device and/or changes thereto. Suchdeterminations can be made, for example, based on the fact that thevoltage across a battery of a device that is connected to a car chargeris likely to exhibit relatively more variability than that of a deviceconnected to a wall outlet. In another example, various determinationscan be performed in order to identify/distinguish between various typesof power charge sources such as solar battery chargers and fixed wallchargers, based on the variability of the power from such sources (e.g.,a power source providing a relatively smaller current, a relatively morevariable current, and/or a current having a relatively more variablevoltage, can be determined to be relatively more likely to be presentwithin a vehicle, and vice versa) that they are able to provide to thedevice battery.

In another implementation, various determinations pertaining to thecontext within which a device is present/operating (e.g., within avehicle) can be achieved based on the temperature of a battery of thedevice. Moreover, and changes in such temperature(s) can be used todetermine one or more contexts of the device (e.g., whether the deviceis within a vehicle). Such determination(s) can be made, for example, inlight of the fact that the temperature of a device that is connected toa car charger is likely to exhibit different characteristics (e.g., moreextreme temperatures) than those exhibited by/observed in relation to adevice connected to a wall outlet.

Moreover, in certain implementations one or more determinationspertaining to a hands-free state of a device (e.g., where the device ispositioned/held within a vehicle) can be made based on one or moreaspects of the power connection status of the device. For example, itcan be appreciated that a device that is connected to a power source isrelatively more likely to be operated by a driver than by a passenger(in light of the fact that, for example, a vehicle is relatively morelikely to have one or more a power connections that are compatible witha device operated by a driver, and the locations such power sources,such as a cradle/dock having a power connection, is relatively morelikely to be positioned in closer proximity to a driver than apassenger, etc.).

In certain implementations, when a device is connected to a power sourceand its context (e.g., within a vehicle vs. outside of a vehicle, withinschool grounds vs. outside of school grounds, etc.) has been identifiedand/or can be determined, one or more further determinations can be madewith respect to the ongoing state/status of such a device. For example,it can be determined that such a device is relatively likely to remainwithin or otherwise maintain the same/comparable context at least untilthe device is no longer connected to a power source. Accordingly, incertain implementations, having determined that a device is connected toa power source, one or more instance(s) (e.g., a “short burst”) ofadditional determination techniques (e.g., contextual determinations,such as those described herein), such as those that may entail higher oradditional power consumption, can be initiated or otherwise employed. Indoing so, a determination of the context within which a device ispresent/operating can be achieved initially (i.e., upon connecting thedevice to a power source) such that, having identified/determined such acontext, various aspects of the power consumption of the device can bereduced (e.g., over the medium and long terms). For example, havingdetermined that a particular device is connected to a power source, oneor more sensors of the device (e.g., GPS, WiFi radio, cellular radio,Bluetooth radio, accelerometer, gyroscope, etc.) can be turnedon/activated, such as for a period of time, in order to obtain/receiveone or more inputs based upon which it can be determined whether thedevice is (or is not) present/operating within a vehicle. Based on adetermination that the device is not present/operating within a vehicle,it can be further determined that the device is subsequently notpresent/operating within a vehicle as long as and/or at least until suchtime as the device is determined to no longer be connected to a powersource (and/or connected to the power source with respect to which thedevice was initially connected). Based on a determination that thedevice is present/operating within a vehicle, it can be furtherdetermined that such a state/status is likely continue, and thus thatthat the device is to continue to be present/operating within thevehicle, at least until such time as is the device is determined to nolonger be connected to a power source (and/or connected to the powersource with respect to which the device was initially connected).

In certain implementations, the manner in which one or moredeterminations are made, such as with respect to the context of a devicewithin a vehicle (e.g., trip start, trip end, vehicle class, in-vehiclerole, in-vehicle location, etc., such as are described herein) can befurther configured, modified, adjusted, etc., based on/with respect towhether or not the device can be determined to be (or has or has notrecently been) connected to power (e.g., the various techniques that areused to compute the referenced determinations can be adjusted or changedbased on whether a device is and/or isn't connected to power). Forexample, when a mobile device is connected to power, it may use its GPSradio more intensively (without depleting the device's battery), eitherdirectly and/or indirectly (e.g., by leveraging other OS processes oruser processes that may do so), to help determine one or more contextsin which the mobile device is in (e.g., trip start, trip end, vehicleclass, in-vehicle role, in-vehicle location, etc.).

It can be appreciated that one or more of the techniques describedherein operate based on the assumption that power sources (with respectto which the various determinations are computed) are non-nomadic (i.e.,that such power sources/supplies are fixed in a particular location).Accordingly, while in certain situations nomadic power sources/suppliescan also be implemented (e.g., external batteries, portable powersources, etc.), the use of such nomadic power sources can bedetermined/detected and/or otherwise accounted for in a number of ways.For example, the usage of such nomadic power sources can be determinedbased on the level of current or voltage identified at the device/batter(and/or changes thereto), and/or via the magnetometer of the device(and/or changes thereto), and/or based on one or more movement patternsthat can be identified as being consistent with the use of a heavierdevice, as can be determined based on one or more inputs originatingfrom various motion sensors of the device (e.g., accelerometer,gyroscope). Additionally, such nomadic power sources are relatively lesscommon and/or can entail various barriers to user adoption (e.g., cost,size, weight, being cumbersome, etc.). Moreover, one or more of thereferenced determinations can be accumulated/maintained over time, suchas with respect to a particular device, a user/user account associatedwith a device, etc. As such, a device and/or a user/user account thathas been determined (such as on an ongoing basis) to utilize a nomadicpower supply, the referenced techniques (which, for example, determine acontext of a device based upon a power connection state/status of thedevice) can be utilized relatively more selectively and/or not at allwith respect to such devices.

In certain implementations, based on a determination that a device isconnected to a power source, a scan of WiFi access points that areperceptible to the device can be initiated or otherwise performed, suchas at one or more intervals. In doing so, the number/quantity of and/oridentities (e.g., service set identifiers or ‘SSIDs’) associated withWiFi access points that are subsequently perceptible at the device canbe compared to an initial/previous number/quantity of and/or identitiesassociated with WiFi access points perceptible at the device. In doingso, a determination can be made with respect to whether or not (and/orwhen) the device is moving, such as is described in greater detailherein. For example, in a scenario where access points A, B and (areperceptible at a device, and at a subsequent time only access points D,E and F are visible, it can be determined that it is relatively likelythat the device has moved (on account of the changing identities of theaccess points perceptible at the device).

Moreover, scenarios can arise whereby, at one time/interval there wereno (or relatively fewer) access points perceptible, and at a laterinterval there are one (or relatively few new/additional) access pointsvisible. It can be appreciated that, in such scenarios, determinationspertaining to whether the device has moved may be relatively lessaccurate (in light of the fact that a single newly perceived accesspoint may have just been turned on despite the fact that the deviceremains stationary). Accordingly, in certain implementations one or moretimestamp(s) contained/embedded within the access point beacon can beused to determine an uptime of the access point. Based on adetermination that the uptime of the access point is relatively low, itcan be further determined that the access point is likely to have beenturned on relatively recently and the referenced change(s) with respectto the perception of various access point(s) under such circumstancesmay thus not provide accurate determinations with respect to themovement of the device. However, based on a determination that theuptime of the access point is relatively high, the referenced change(s)with respect to the perception of various access point(s) can providerelatively accurate determinations with respect to movement of thedevice, as described herein.

In certain implementations, the context within which a device ispresent/operating (e.g., within a car vs. at an office vs. at home) canbe determined in relation to various aspects of the powerconnectivity/connection associated with the device, by using one or moremachine learning techniques (as are known to those of ordinary skill inthe art) to identify, such as over time, one or more patterns,properties, and/or characteristics associated with various powersources/chargers that the device connects to and/or associating suchpatterns, properties, and/or characteristics with one or more contexts.That is, it can be appreciated that many users can utilize differentpower sources/chargers in different locations (e.g., a USB charger atwork, a cigarette lighter charger in the car and a wall charger athome). Such power sources can have different electrical properties(current, voltage, etc.) that can be perceived at/in relation to thedevice (e.g., USB charger in the office may charge the battery of aparticular device at 240 mAh, thereby charging the battery at a rate of0.2%/minute, while a car charger may charge the battery at 600 mAh,thereby charging the battery at a rate of 0.5%/minute, and an AC wallcharger at home may charge the battery at 1200 mAh, thereby charging thebattery at a rate of at 1%/minute. Accordingly, for example, based onone (or more determinations) that the battery of the device is beingcharged at a rate of 0.5%/minute concurrent with or otherwisechronologically proximate to a time with respect to which such a devicecan also be determined to be present/operating within a vehicle (such asa moving vehicle), it can be further determined, with respect to theconnection of such a device to a power source and charging of thebattery of the device at a rate of 0.5%/min, that suchcharacteristics/aspects indicate that it is relatively likely that thedevice is present/operating within a vehicle.

In certain implementations, one or more connectivity state(s) of thedevice can be used to determine whether or not the device ispresent/operating within a vehicle. For example, based on adetermination that the device is connected to a WiFi access point, theperformance of various power consuming operations (that might otherwisebe performed by/in relation the device, such as using the GPS of thedevice to determine whether the device is moving) can be avoided and/orlimited (such as by performing such operations less frequently).Moreover, the device can continue to operate in such a fashion (i.e.,avoiding/limiting the use of such operations) until the referenced WiFiconnection is terminated (and/or shortly thereafter). It can beappreciated that, in light of the fact that relatively few vehicles haveWiFi access points, an ongoing connection to a WiFi access point canindicate that the device is relatively unlikely to be in a vehicle.Moreover, in certain implementations, based on a determination that adevice is/is not connected to a Wifi AP, it can be determined that sucha device is not/is present within a vehicle (such as a moving vehicle).Moreover, in certain implementations, one or more operations can beinitiated, such as with respect to the device (e.g., employing,modifying, removing various restrictions that are employed with respectto the operation of the device).

Moreover, in certain implementations one or more of the technologiesdescribed herein can incorporate one or more machine learningtechniques, such as with respect to the WiFi access points that areperceptible to a particular device. In doing so, one or moredeterminations can be made, such as with respect to whether (a) anaccess point is static/stationary (e.g., within a home, office, etc.),as can be determined, for example, based on one or more perceptions ofsuch WiFi access points by the device concurrent with and/or inchronological proximity to one or more determinations that indicate thatthe device is unlikely to be moving, or (b) an access point isdynamic/mobile (e.g., within or on a car, train, bus, etc.) based on oneor more perceptions of such WiFi access points by the device concurrentwith and/or in chronological proximity to one or more determinationsthat indicate that the device is likely to be moving. The referenceddeterminations can be made, for example, by measuring the one or moreaspects of the motion(s) that can be perceived by/in relation to thedevice (based on one or more inputs that can originate, for example,from information/sources such as GPS, cellular IDs, cellular RSSI, WiFiIds, Wifi RSSI, accelerometer, gyroscope, etc.) concurrent with and/orin relatively close proximity to one or more determinations that thedevice is connected to (or is otherwise able to perceive or “hear”without necessarily being connected to) a WiFi access point (or throughthe use of a third-party database of Wifi access points, such asSkyhook, based upon which and/or in relation to which suchdeterminations can be made).

Moreover, the context within/in relation to which a device ispresent/operating (e.g., whether a trip, such as in a vehicle, hascommenced, whether the device is within a moving vehicle, whether thedevice is with a user walking, the vehicle class of a vehicle, etc.) canbe determined based on various determinations/identifications. Forexample, in certain implementations, based on (a) a determination that adevice is connected to a power source, and (b) a determination that oneor more wireless (WiFi), Bluetooth, cellular, etc., signals (such asthose originating from a WiFi access point) and/or one or more inputsoriginating at one or more sensors (e.g., accelerometer, gyroscope,magnetometer, proximity, pressure, light, camera, microphone, etc.), arechanging (e.g., changing above a certain threshold/degree of change)(e.g., different WiFi access point BSSIDs are determined to be cominginto/out of view, cell tower signal strengths are determined to bechanging more than a certain amount, etc.), it can be determined thatthe device is likely to be within a moving vehicle. Moreover, it can bedetermined that the device is relatively less likely to be in certaintypes of moving vehicles (e.g., bicycle, elevator) because devices arerelatively less likely to be connected to power in such situations. Inaddition, upon determining that a device is connected to a power source,one or more of the various determination techniques described herein(such as those pertaining to aspects of the power connectivity and/orpower consumption of a device) can be employed. In doing so, suchdeterminations with respect to the context of the device can be utilizedto conserve power (e.g., by deactivating, utilizing relatively lessfrequently and/or in a different way, and/or not utilizing at all, oneor more sensors, functions, and/or operations of the device, such asthose that consume power, based on the determined context of thedevice). Such functionality can be advantageous even when a device isconnected to a power source (e.g., an AC outlet) because a user may onlyhave a limited amount of time to charge his/her device and utilizingrelatively less power can enable the battery to charge more quickly.

Additionally, in certain implementations (including in scenarios where adevice may or may not be connected to power), based on (a) adetermination that one or more wireless (WiFi), Bluetooth, cellular,etc., signals (such as those originating from a WiFi access point) arechanging (e.g., changing above a certain threshold/degree of change)(e.g., different SSIDs are determined to be coming into/out of view,signal strengths are determined to be changing more than a certainamount, etc.), and (b) a determination that the device is not moving ina manner consistent with one or more activity types and/or vehicleclasses (e.g. the device is determined to be moving in a mannerconsistent with a user walking, a user bicycling, a user riding anelevator, etc.) and/or in the absence of a determination that the deviceis moving in a manner consistent with such one or more activity typesand/or vehicle classes (as can be determined, for example, in the caseof user walking, using various pedometric determination techniques, asare known to those of ordinary skill in the art, or in the case of auser in an elevator, for example, using a pressure sensor on the deviceto determine a relatively significant change in pressure over arelatively short time and/or distance), it can be determined that thedevice is likely to be present in conjunction with certain activitytypes and/or within certain vehicles classes types. In making suchdeterminations based on the referenced factors (e.g., changes pertainingto WiFi access points), a determination that a device is, for example,present within a moving vehicle, can be made even without the use of thedevice's GPS (which can otherwise entail considerable batterydischarge).

It should be noted that the utilization of techniques that enable thedetermination of the activity being performed and/or the vehicle classbeing used by eliminating (or otherwise determining a relatively lowlikelihood of) certain types of activities or vehicles (i.e., via a‘process of elimination’) can, in certain scenarios, enable relativelymore effective and/or efficient determination as to which activity isbeing performed and/or vehicle class is being used than afforded throughthe use of ‘positive’ or affirmative activity or vehicle classidentification/determination techniques. As in the above example, it canbe relatively easier/efficient, more accurate, require less power,and/or faster to determine that it is relatively likely that a device isin a moving vehicle by determining that the device is not present with auser walking, than by affirmatively determining that the device isrelatively likely to be present within a moving vehicle (e.g., based ona determination that its spectral frequency is within a certain range,etc., as described herein). For example, based on a determination adevice is connected to a power source, it can be further determined(even without having to use any additional battery power) that thedevice is relatively unlikely to be with a user who is walking orcycling. For example, determining that the device is not present with auser who is walking can be achieved by sampling an accelerometer and/orgyroscope for signs/indications/patterns of walking, which can be doneat a relatively lower sampling rate (thereby consuming less batterypower) than otherwise required to determine that the device is presentwithin a moving vehicle.

In certain implementations, based on a determination that a user/devicehas moved more than a certain distance (e.g., more than a distance thatcould otherwise be attributed to GPS ‘noise,’ even if not moving), suchas within a certain period of time, and further based on a determinationthat the device has not been operating in a manner that can bedetermined to be sufficiently consistent to walking (such as within thereferenced period), the user/device can be determined to be presentwithin a moving vehicle.

It should be noted that the various techniques described herein(including the referenced ‘negative’ or ‘reverse’ determinations thatare based on one or more determinations of context(s) that a device isnot present with respect to) can be employed in order to make any numberof determinations, including but not limited to: activitydetermination(s), vehicle movement determination(s), and/or vehicleclass determination(s). In doing so, such determinations can be achievedeven in scenarios/situations where determination-related ‘blind spots’might otherwise be present, such as in scenarios where GPS signals arenot available or otherwise reliable (e.g., in tunnels, undergroundgarages, cities with tall buildings, indoors, inclement weather, etc.).

It should also be noted that the various techniques described herein canalso enable the identification/determination of vehicles moving atpractically any speed (in contrast to otherwise waiting for the vehicleto reach a speed at which it can be determined that an unaided humancannot reasonably travel in order to affirmatively determine that adevice is present within a moving vehicle). In employing suchtechniques, it can be determined that a device is present within amoving vehicle even in a scenario where the vehicle is moving at arelatively slow speed.

Additionally, upon identifying/determining that a device is presentwithin a moving vehicle, it can be further determined that such a deviceis no longer present within a moving vehicle uponidentifying/determining that the device is present in conjunction with‘walking.’ (It should be noted that the terms ‘walking,’ ‘user walking,’etc., as used herein are intended to encompass any and/or all forms ofunaided human movement, such as walking, running skipping, etc.)

Accordingly, it can be appreciated that employing one or more of thereferenced techniques can enable determination(s) of one or moreactivities, operations, presence of a device within a moving vehicle,vehicle class(es), etc., without the use of GPS. In addition, in variousimplementations, the GPS of a device can, for example, be utilized onlywhen other signals are not sufficiently strong, clear, accurate, etc.,and/or to confirm the accuracy of such other determinations.

It should be further noted that, in certain implementations, one or moredeterminations can be made with respect to vehicle class based on theperception/identification of one or more RF devices (e.g., WiFi APs, BTdevices, etc.) that are in proximity of/present within the vehicle. Inorder to do so, for example, the identity (e.g., BSSID, SSID, MACaddress, etc.) of the RF device can be used to determine a likelihood ofa particular vehicle class (with respect to which the device ispresent). In doing so, it can be detected/determined that the device ispresent within a moving vehicle (such as in the manner describedherein). An identity of one or more related/comparable/similar RFdevices can be identified/determined, such as based on/in relation to adatabase that can maintain identities of various RF devices and theirrespective associated vehicle classes (as determined, for example, basedon inputs originating at one or more sensors of various devices, such asin the manner described herein). Moreover, one or more determinations(e.g., of a vehicle class) can be made based on similar, related, and/orcomparable (even if not identical) RF device identity information, suchas that stored/maintained in such a database. For example, in a scenariowhere a first BSSID of a WiFi AP is close/similar/comparable/related toanother BSSID of another WiFi AP that is identified/has been determinedto be in a public bus, the first BSSID can be determined to be likely tobe operating in relation to a bus, too (in light of the fact that buscorporations tend to purchase in bulk and are relatively likely toreceive successively/closely numbered devices). For example, if a datavalue of an RF device, like a WiFi AP's SSID, is an SSIDidentified/determined to be used in a public train (e.g.,“AmtrakConnect”), then it can be determined, with respect to another RFdevice having the same SSID or a similar/comparable SSID (e.g.,“AmtrakConnect2”) that such a device with the same/comparable SSID isalso on a public train. It should be noted that potential errors in suchdeterminations that may arise can be corrected by using one or moretechniques (such as those described herein) to validate the determinedvehicle class in relation to such RF devices. Additionally, the RFdevices operating in relation to vehicles in certain vehicles classes(e.g., buses, trains) are relatively likely to be perceived by multiplemobile devices simultaneously and over time than, for example, in a car.As such, one or more determinations as to the class of a vehicle can bemade based on the relative quantity of devices that perceive such an RFdevice simultaneously and/or over time. Thus, the greater the number ofdevices determined to simultaneously and/or over time perceive aparticular RF device, the relatively more likely it is that such devicesare present within certain types of “mass” vehicle classes (e.g., train,bus, etc.). Moreover, such RF device(s) can be associated with aparticular vehicle class on that basis, and/or using one or moretechniques such as those described herein.

The accuracy of such determinations can be further improved over time.For example, observing the same and/or similar changes with regard tocertain access points—such as during a trip—multiple times, can furtherconfirm that subsequent comparable observations can also be determinedto be occurring during a trip. It should also be noted that the accuracyof the referenced determinations can be further improved based on adetermination that the referenced signals (e.g., those originating fromWiFi access points, etc.) originate from a nomadic and/or non-nomadicsource, as determined, for example, using one or more of the techniquesdescribed/referenced herein. Moreover, in scenarios where the variouswireless, etc., signals are not available (or cannot otherwise be reliedupon), the GPS can be utilized, alone or in conjunction with othersignals and/or sensors), to determine whether the device is presentwithin a moving vehicle, etc. It should also be noted that one or moreadditional determinations can be made (e.g., upon determining that adevice is within a moving vehicle), such as with regard to the type ofvehicle that the device is in (e.g., car, boat, train, bus, etc.), suchas in the manner described herein.

In addition, in certain implementations one or more determinations canbe made with respect to the characterization and/or classification ofvarious WiFi access points (such as stationary/static/fixed/non-nomadicor mobile/dynamic/nomadic). Such determinations can be made, forexample, based on (a) information accumulated/stored by/in relation to adevice (such as over time), (b) information accumulated by/in relationto multiple devices (i.e., ‘crowd-sourced’) (such as over time), (c)based on information contained/identified within various WiFi broadcasts(reflecting, for example, the manufacturer, model, etc., of an accesspoint), as can be identified, for example, based on one or morecomparisons with one or more databases (as can be stored on the deviceand/or remotely) that contain data pertaining to which manufacturers,models, etc. are likely to be utilized instationary/static/fixed/non-nomadic or mobile/dynamic/nomadic contexts,and/or (d) in conjunction with third party services.

In another implementation, one or more of the contextual determinationsdescribed herein can be further configured to operate based on/inrelation to a premise/default/assumption that a device is notpresent/operating within a vehicle based on a determination that such adevice is connected to an access point that can be determined to benon-nomadic access point (i.e., an access point that can be determinedto have a relatively fixed location and/or whose location is notdetermined to change relatively regularly). Examples of such anon-nomadic/stationary access point can include a WiFi access point inan office network (in contrast to an in-vehicle WiFi access point or amobile device that can serve as a WiFi access point, a such devices canbe determined to be mobile).

It should be noted that, in certain implementations, the manner in whicha particular access point, such as a WiFi access point, can bedetermined to be non-nomadic/stationary can be achieved in a number ofways. For example, in certain implementations the nomadicity (that is,the nomadic/non-nomadic state/status) of an access point can bedetermined based on/in relation to a database (local or remote) that canmaintain information pertaining to various access points, and/or thatcontains respective classifications of such access points, such as inrelation to the nomadic/stationary and/or non-nomadic/mobilecharacteristics/properties of such access points (e.g., BSSIDs). Such adatabase can be built/compiled, for example, based on the results ofvarious nomadic/non-nomadic determinations that can be performed withrespect to various access points, such as is described herein (withrespect to individual devices and/or accumulated across devices, such asvia ‘crowd-sourcing,’ and/or utilizing a third party database of WiFiaccess points, such as Skyhook, that can provide the referencednomadic/non-nomadic information/determinations, or, based on adetermination that, by virtue of the method with respect to whichinformation pertaining to such WiFi access points wascollected/gathered, that the referenced WiFi access pointrecords/entries pertain to non-nomadic access points.

Moreover, in certain implementations the nomadicity of a an access pointcan be determined by querying/looking up the referenced access pointwithin a database (local or remote) that maintains associations of thecontext within which the device is present/operating with an identifierof the WiFi access point (e.g., a BSSID) that is the device is/wasconnected to. Such a database can be generated based on the results ofone or more determinations that pertain to the context within which adevice is present/operating in relation to the access point to which thedevice is connected, as described herein (both with respect toindividual devices and/or accumulated across devices, such as via‘crowd-sourcing,’ and/or may be a third party database of access pointsthat provides such information. For example, based on a determinationthat on multiple instances a device was connected to a particular WiFiaccess point and was also determined not to be present/operating withina vehicle, then upon subsequently determining that the device is againconnected to the same WiFi access point, it can be determined that thedevice is again relatively likely t not to be present/operating within avehicle.

Additionally, in certain implementations, one or more of the referenceddeterminations can also incorporate and/or otherwise consider aspectspertaining to BSSID, Beacon, and/or WPS transmissions. For example,based on one or more of such items the identity of the manufacturer ofthe WiFi access point to which the device is connected can beidentified. By way of illustration, a BSSID of an access point can beused to identify the manufacturer. And, having identified themanufacturer, such an identity can be used to further increase theaccuracy of the referenced determination(s). For example, in a scenariowhere the BSSID of the WiFi access point to which a device is connectedis that of a manufacturer that makes mobile phones, it can be determinedthat there is a relatively greater likelihood that such an access pointis nomadic. Moreover, based on such a determination the context of sucha device can be further analyzed/checked (i.e., rather than solelyrelying on the connection of the device to the referenced access pointin order to determine the context of the device). For example, a WiFiaccess point having a BSSID prefix of 40:A6:D9 is assigned to WiFiaccess points made by Apple and can thus be determined to be relativelylikely to be an iPhone 4.

It should be noted that a database can also be utilized incases/scenarios where a manufacturer produces both nomadic andnon-nomadic devices, in light of the fact that such devices often havemultiple prefixes and different prefixes can pertain to differentdevices. Moreover, with respect to a given BSSID prefix, the value ofthe BSSID suffix (i.e., the last 6 characters of the 12-character BSSIDand which are generally assigned contiguously to similar/comparabledevices), can be compared to such a database in order to furtherdetermine the nomadicity of such an access point.

Moreover, in certain implementations additional information (e.g.,device type, model name, model number, etc.) pertaining to an accesspoint can be obtained, such as from WPS (WiFi Protected Set-Up)information of the access point, and such information can be used withrespect to determining the context and/or nomadicity of the accesspoint. For example, with respect to manufacturer the produces bothnomadic and non-nomadic WiFi access point under the same BSSID prefix,the model number of model name of the device (e.g. “Automotive WiFi HotSpot” or “Enterprise AP with 1 GB bandwidth”) can be used in order toidentify/determine whether the as access point is nomadic or non-nomadicand/or otherwise determine the context within which the device ispresent/operating.

Additionally, in certain implementations the nomadicity of an accesspoint can be determined based on whether the device can be determined tobe moving at the time it is also determined to be connected to theaccess point (such movement can be determined, for example, based on oneor more inputs/sources such as GPS, cellular IDs, cellular RSSI, WiFiIDs, Wifi RSSI, accelerometer, gyroscope, etc., such as are describedherein). In doing so, an access point can be characterized/classified asbeing nomadic based on a determination that the connected device wasmoving concurrent with and/or in relatively close chronologicalproximity to being connected to the referenced access point, while beingcharacterized/classified as non-nomadic based on a determination thatthe device was not moving concurrent with and/or in close chronologicalproximity to being connected to the referenced access point. Moreover,as described herein, the context of the device (e.g., being mobile orstationary while connected to the access point) can be recorded inrelation to the access point.

In other implementations, in addition to determining that a device isnot present/operating within a vehicle based on a determination that thedevice is connected to an access point determined to be non-nomadic, adevice can be positively/affirmatively determined to bepresent/operating within a vehicle based on a determination that thedevice is connected to an access point determined to be nomadic.

Moreover, with respect to access points having relatively higher powertransmissions (and therefore cover larger geographic ranges), it can beappreciated that the connection of a device to such access point(s) canbe relatively less indicative of the fact that the connected device isnot present/operating within a vehicle (as opposed to access pointshaving a relatively shorter transmission range). In suchcase(s)/scenario(s), one or more techniques (such as the RSSI technique)described herein can be utilized in order to make a determinationregarding the nomadicity of the access point.

In certain implementations, one or more of the access points that areperceptible to the device (e.g., other than an access point that thedevice is connected to), such as while scanning with the WiFi radio ofthe device, can be analyzed to determine the context of the device.Moreover, in certain implementations the access point to which thedevice is connected (if it is so connected) can be classified asnomadic/non-nomadic and saved (locally and/or remotely) for future use(such as by this device and/or with other devices), such as using one ormore techniques, such as those described herein. For example, in certainimplementations an access point perceived by a device can becharacterized/classified as nomadic/non-nomadic based on aquery/identification of a database containing a record of such an accesspoint (and/or a comparable access point based upon which suchdetermination can be made) and/or by making such determinationdynamically, such as based on information received/derived from theBSSIDs (e.g., manufacturer, model) and/or WPS information (e.g., model)of an access point. Thus, if a device can perceive one or more accesspoints that are known or have been determined to be non-nomadic accesspoints (such as over some period of time, in order to account fornomadic access points that may be perceptible to a moving device forrelatively short periods of time), such a device can be furtherdetermined to be stationary/not in motion. Moreover, if the device canperceive one or more access points determined to be nomadic (such asover some defined period of time), such a device can be determined to bein motion.

By way of further example, in certain implementations one or morecontexts associated with one or more of the access points that areperceptible to a device can be used to determine, with a certain degreeof likelihood, the current context of the device. For example, in ascenario where, upon perceiving a particular access point (such as anaccess point located in the vehicle of another user, such as when such auser parks in a company parking lot), it can be determined that thedevice is not present/operating within a vehicle, upon subsequentlyperceiving the same access point, it can be further determined that thedevice is, again, not present/operating within a vehicle.

By way of yet further example, in certain implementations one or moreother access points (e.g., those access points other than the one thatthe device is connected to) that are perceptible to the device can beanalyzed, such as across successive/intermittent scans of the WiFi radioof the device, such as even in scenarios where the nomadic/non-nomadiccharacterization/classification of such access points may not yet bedetermined. Based on a determination that one or more of (e.g., thecollection of) perceived access points across multiple/successive scansis substantially similar (and there are a relatively sufficient quantityof access points that are perceptible in such scans), then it can befurther determined that the device is not moving. However, based on adetermination that the collection of such perceived access points acrossmultiple/successive scans is relatively dissimilar, it can be determinedthat the device is moving. Moreover, the accuracy of determinationsachieved using such technique(s) can be increased/improved by analyzingthe RSSIs of the perceived access points in the collection (as opposedto looking at the presence or lack thereof of each access point acrossmultiple/successive scans. For example, in a scenario wheremultiple/successive scans are relatively close in time to one anotherand/or the device is moving relatively slowly, multiple/successive scansof perceptible access points using the WiFi radio of the device maydemonstrate a substantially similar collection of access points, but ifsome of the referenced RSSI values have changed substantially, it cannevertheless be determined that the device is likely in motion.

In certain implementations, the speed at which a device is moving can bedetermined/estimated based on a determination of the distance between(a) the location of the device at the time that the WiFi radio of thedevice is used to perform a first access point scan (e.g., as determinedfrom the known/determined locations of one or more of the BSSIDs, suchas from a 3^(rd) party database such as Skyhook, and further using errorminimization techniques to calculate the location of the device, such asbased on the respective locations of each of the access points that areperceptible to the device with or without using the RSSIs of such accesspoints as described herein, and (b) the location of the device at thetime that the WiFi radio of the device is used to perform another accesspoint scan, relative to the amount of time that elapsed between the twoscans. It should be noted that such a technique can be implemented withmore than two access point scans as well.

Moreover, in certain implementations the speed at which a device ismoving can still be determined/estimated even without locationinformation regarding (non-nomadic) WiFi access points. Suchdetermination(s) can be achieved, for example, based on changes in theRSSI of the WiFi access points across multiple/successive scans. Forexample, an access point whose RSSI on a device changes from −30 dB to−90 dB over the course of a relatively short period of time (e.g., 1second) can be determined to be relatively likely to bepresent/operating within a vehicle because, given the transmission rangeof WiFi access points, it is relatively unlikely that the device wouldbe capable of moving at such a rate of speed without being presentwithin a vehicle. However, with respect to an access point whose RSSI ona device changes from −30 dB to −31 dB over the course of a comparabletime period can be determined to be unlikely to be present within amoving vehicle because, given the transmission range of (most) WiFiaccess points, a moving vehicle is relatively likely to experience arelatively larger change in the strength of the signal received than 1dB, even over a relatively short period of time.

Moreover, in certain implementations, one or more techniques similar tothose described herein with respect to access points such as WiFi accesspoints can be employed with respect to determining a context withinwhich a device is present/operating based on the Bluetooth (BT)connectivity state/status of such a device. For example, based on adetermination that the device is connected to a nomadic BT device (e.g.,a hands-free car loudspeaker), it can be determined that the device ispresent/operating within a vehicle. Moreover, based on a determinationthat the device is connected to a non-nomadic BT device (e.g., a desktopcomputer), it can be determined that the device is not present/operatingwithin a vehicle. As described herein with respect to access points, aBT device (to which a device is connected) can becharacterized/classified as nomadic/non-nomadic in a number of ways. Forexample, in certain implementations the nomadicity of a BT device can bedetermined based on/in relation to a database (local or remote) that canmaintain information pertaining to various BT devices, and/or thatcontains respective classifications and/or characterizations of thenomadic/non-nomadic properties of various BT devices (BSSIDs). Suchdatabase can be built/compiled, for example, based on the results of oneor more of the nomadic/non-nomadic determinations described herein, bothwith respect to individual devices and/or accumulated across devices(‘crowd-sourcing’) and/or may be a third party database of BT devicesthat provides such nomadic/non-nomadic information.

Moreover, in certain implementations the nomadicity of a BT device canbe determined by querying/looking up the referenced BT device within adatabase (local or remote) that maintains associations of the contextwithin which the device is operating in relation to an identifier of theBT device (BSSIDs) that is the device was/is connected to. Such databasecan be generated/built based on the results of one or moredeterminations that pertain to the context within which a device ispresent/operating in relation to the BT device to which the device isconnected, as described herein (both with respect to individual devicesand/or accumulated across devices, e.g., via ‘crowd-sourcing,’ and/ormay be a third party database of BT devices that provides suchinformation. For example, based on a determination that on multipleinstances a device was connected to a particular BT device and it wasalso determined not to be present/operating within a vehicle, then uponsubsequently determining that the device is again connected to the sameBT device, it can be determined that the device is again relativelylikely not to be present/operating within a vehicle.

Additionally, in certain implementations, one or more of the referenceddeterminations can also incorporate and/or otherwise consider aspectspertaining to BSSIDs. For example, the identity of the manufacturer ofthe BT device to which the device is connected can be identified, suchas is described herein. For example, the BSSID of a BT device can beused to identify its manufacturer. And, having identified themanufacturer, such an identity can be used to further increase theaccuracy of the referenced determination(s). For example, in a scenariowhere the BSSID of the BT device to which the device is connected isdetermined to be that of a manufacturer that produces hands-free carloudspeakers, it can be determined that there is a relatively greaterlikelihood that the BT device is nomadic, whereas based on adetermination that the BSSID of the BT device to which the device isconnected is that of a manufacturer that produces desktop computers, itcan be determined that there is a relatively greater likelihood that theBT device is non-nomadic.

It should be noted that a database can also be utilized incase(s)/scenario(s) where a manufacturer produces both nomadic andnon-nomadic devices, in light of the fact that such devices often havemultiple prefixes and different prefixes relate to different devices.Moreover, with respect to a given BSSID prefix, the value of the BSSIDsuffix (i.e., the last 6 characters of the 12-character BSSID and whichare generally assigned contiguously to similar/comparable devices), canbe compared to such a database in order to determine the nomadicity ofsuch a BT device.

Moreover, in certain implementations one or more of the referenceddeterminations can also incorporate and/or otherwise consider aspectspertaining to beacon transmission(s) pertaining to various BT devices,such as by querying/looking up the device class(es) (major and minor)and/or services class(es) of a particular BT device. For example, if adevice (e.g., a mobile device such as a smartphone) is connected to ahands-free BT device (having a BT major class of ‘Audio Video’ and a BTminor class of ‘Hands-Free’), it can be determined that the device (thatis, the mobile device) is relatively likely to be present/operatingwithin a vehicle. Based on such a determination, one or more powerconsuming operations (that may have otherwise be performed, such as inorder to determine the context of the device, e.g., using the GPS todetermine if the device is moving) need not be performed (or can beperformed relatively less often) until the BT connection is determinedto have been terminated (and/or relatively shortly thereafter).Alternatively, based on a determination that a device is connected viaBT to a desktop computer (having a BT major class of ‘Computer’ and a BTminor class of ‘Desktop’), the device can be determined to be relativelyunlikely to be present/operating within a vehicle. Based on such adetermination, one or more power consuming operations (that may haveotherwise be performed, such as in order to determine the context of thedevice, e.g., by using the GPS to determine if the device is moving)need not be performed (or can be performed relatively less often) untilthe BT connection is determined to have been terminated (and/orrelatively shortly thereafter).

Moreover, one or more of the referenced determinations can be made basedon a determination that a device was moving at the time it is connectedto the BT device (as determined, for example, based on GPS, Cell IDs,Cell RSSI, Win IDs, Wifi RSSI, accelerometer, gyroscope, etc., asdescribed herein), and a characterization/classification of the BTdevice to which the device is connected as nomadic based on adetermination that the device was moving while it was connected to theBT device (and non-nomadic if the device was determined not to be movingwhile it was connected to the BT device), and/or by recording orassociating the determined context of the device with the BT device.

In another implementation, the BT device(s) that are perceptible to adevice (such as a mobile device such as a smartphone) when scanning withits BT radio (other than the BT device that the device is connected to),can be used to determine the context of within which the device ispresent/operating (it should be understood that the referenced scans forBT devices can be made for discoverable and/or paired BT devices).Moreover, in certain implementations the BT device to which a device isconnected (if it is so connected) can be characterized/classified asnomadic/non-nomadic, and such characterization/classification can besaved (locally or remotely) for future use (such as by the referenceddevice and/or by other devices). It should be understood that suchdeterminations can be made in a number of ways. For example, in certainimplementations the nomadicity of a device (such as a mobile device suchas a smartphone) can be determined based on/in relation to thenomadic/non-nomadic characterization(s)/classification(s) of the BTdevices it perceives (such as by identifying records/informationcorresponding to such BT devices within a database) and/or making suchdeterminations dynamically based on one or more determinations withrespect to one or more combinations of information corresponding to themanufacturers, major and minor classes and services of such BT devices.In doing so, based on a determination that a device perceives, for arelatively/sufficiently long period of time (e.g., in order to filterout/account for non-nomadic devices that a moving device may perceivefor relatively short periods of time) one or more BT devices that havebeen determined to be nomadic, the referenced device can be determinedto be in motion, whereas if the device perceives, for asufficiently/relatively long period of time, one or more BT devices thathave been determined to be non-nomadic, the device can be determined notto be in motion.

Moreover, in certain implementations the nomadicity of a device can bedetermined based on/in relation to how one or more of the BT devicesthat are perceptible to the device has/have been previously associated,such as with a particular context. In doing so, one or moredeterminations can be made with respect to the present context of thedevice. For example, based on one or more instances with respect towhich a device perceives a particular BT device (e.g., the BT earpieceof another user) and also determines that the device is notpresent/operating within a vehicle, upon a subsequent perception by thedevice of the same BT device, it can be further determined that thedevice is (again) not present/operating within a vehicle (i.e., evenwithout making such a determination affirmatively).

Moreover, in certain implementations the nomadicity of a device can bedetermined based on/in relation to an analysis of the collection ofother BT devices (i.e., those BT Devices other than the one that thedevice is connected to) that the device perceives/“hears,” such asacross successive scans of its BT radio, even if the nomadic/non-nomadicclassification of such BT devices is not yet known. If the collection ofBT devices across successive scans is determined to be substantiallysimilar (and there are sufficiently many BT devices that are perceptiblein such scans), then the device can be determined not to be moving. If,however, the collection of BT devices across successive scans isdetermined to be substantially dissimilar, then the device can bedetermined to be moving.

The accuracy of such a technique can be increased/improved based on ananalysis of the RSSIs of the BT devices in the collection (e.g., ratherthan solely/primarily considering the Boolean existence/non-existence ofeach BT device in successive scans). For example, in a scenario wheremultiple/successive scans are sufficiently close in time and/or thedevice is moving relatively slowly, multiple/successive scans of BTdevices using the device's BT radio may be determined to demonstrate asubstantially similar collection of BT devices, however if some of theRSSI values can be determined to have changed substantially, the devicecan be determined to be likely to be in motion (i.e., relative to the BTdevices).

In another implementation, the speed at which the device is moving canbe determined/estimated by determining the distance between (a) thelocation of the device at the time that its BT radio is used to performa first BT device scan (e.g., as determined based on the known locationsof each of the (presumably non-nomadic) BSSIDs, such as from athird-party database, and using an error minimization technique tocalculate the location of the device based on the respective locationsof each of the BT devices perceived/“heard” with or without using theRSSIs of such devices, and (b) the location of the device at the timethat its BT radio is used to perform a second or subsequent BT devicescan, relative to the amount of time that elapsed between the two scans.It should be noted that this technique can be implemented with more thantwo BT device scans as well.

Moreover, even without location information regarding (non-nomadic) BTdevices, the speed at which the device is moving can still bedetermined/estimated, such as based on the changes identified in theRSSI of the BT devices in multiple/successive scans. For example, a BTDevice whose RSSI perceived on a device changes from −30 dB to −90 dBover the course of a short period of time (e.g., 100 milliseconds) canbe determined to be likely to be in a vehicle because, given thetransmission range of BT Devices, a human is generally un able to movethe distance required to change the signal so much in such a shortperiod of time, whereas a BT device whose RSSI on a device is determinedto have changed from −30 dB to −31 dB over the course of the same timeis relatively unlikely to be in a moving vehicle because, again, giventhe transmission range of (most) BT devices, a moving vehicle is likelyto experience a much larger change in the strength of the signalreceived than 1 dB, even over a short period of time.

It can be appreciated that most, if not virtually all cell towers arenon-nomadic. However, given that their transmission range is generallygreater than that of WiFi access points, the fact that a device isconnected to a cellular tower may provide relatively less specificcontext information than a device being connected to a WiFi accesspoint. Nonetheless, information regarding the cell tower to which adevice is connected can still be utilized to provide valuableinformation regarding the context of the device.

For example, if a device is determined to be connected to a cell towerthat has been previously associated with a particular context, it can bedetermined, with a certain degree of likelihood, that the device ispresent within such context again. For example, it can be determinedthat a particular device will tend to be connected to a certain celltower when the device is in the user's home and, generally, a differentcell tower when the device is in the user's place of work. Accordingly,if a device is connected to either of these cell towers its context canbe determined not to be within a vehicle and thus, if a device ispresently connected to either one of them, it can be determined that thedevice is not present within a vehicle.

The accuracy of this technique can be improved/enhanced by ‘learning’(such as via machine learning techniques as are known to those ofordinary skill in the art) the RSSIs of cell towers for differentcontexts of the device (e.g., not within a vehicle, within a vehicle,etc.), so that, for example, determinations such as (for example): if adevice is determined to be connected to Cell Tower 12345 in LAC 123 atan RSSI of between −90 DB and −80 DB, the device can be determined to belikely not to be in a vehicle, can be achieved.

In another implementation, the cell towers that can be perceived/“heard”by the device when scanning with its cellular radio (other than the onethat the device is connected to) can be used to determine the context ofthe device. For example, based on a determination that a device canperceive/hear one or more cell towers that have been previouslyassociated with a particular context, it can be determined, with atleast a certain degree of likelihood, that the device is present in suchcontext again. For example, it can be determined that a particulardevice will tend to be connected to a certain cell tower when the deviceis present in the user's home and, generally, a different cell towerwhen the device is present in the user's place of work. Accordingly,based on a determination that a device is connected to either of thesecell towers, the context of the device can be determined not to bewithin a vehicle, and thus, based on a determination that a device ispresently connected to either one of them, it can be determined that thedevice is not present within a vehicle.

Moreover, in certain implementations a context of the device can bedetermined based on an analysis of the collection/set of other celltowers (i.e., those cell towers other than the one that the device isconnected to) that are perceptible to the device, such as acrossmultiple/successive scans of its cellular radio. Based on adetermination that the collection/set of cell towers that areperceptible to the device across multiple/successive scans issubstantially similar (and there are sufficiently many cell towers thatappear in such scans), then the device can be determined not to bemoving. If, however, the collection/set of cell towers that that areperceptible to the device across multiple/successive scans issubstantially dissimilar, the device can be determined to be moving.

The accuracy/resolution of such a technique can be improved/increased,for example, based on an analysis of the RSSIs of the cell towers in theset/collection (rather than only looking at the Booleanexistence/non-existence of each cell tower in multiple/successivescans). For example, based on a determination that the successive scansare sufficiently close in time and/or the device is moving slowly,successive scans of cell towers (such as using the device's cellularradio) may show a substantially similar collection of cell towers, butif some of the RSSI values have changed substantially the device can bedetermined to be likely to be in motion.

In another implementation, the speed at which the device is moving canbe determined/estimated by determining the distance between (a) thelocation of the device at the time that its cellular radio is used toperform a first cell tower scan (e.g., as determined from theknown/identified/determined locations of each of the cell tower IDs,such as from a third party database, e.g., Skyhook, and using an errorminimization technique to calculate the location of the device based onthe respective locations of each of the cell towers perceived with orwithout using the RSSIs of such cell towers), and (b) the location ofthe device at the time that its cellular radio is used to perform asecond cell tower scan, relative to the amount of time that elapsedbetween the two scans. It should be noted that such a technique can beimplemented with more than two cell tower scans as well.

Even without location information regarding cell towers, the speed atwhich the device is moving can still be determined/estimated, such asbased on the changes in the RSSI of the cell towers in successive scans.For example, a cell tower whose RSSI on a device changes from −30 dB to−90 dB over the course of a short period of time (e.g., 1 second) can bedetermined to be relatively likely to be present within a vehiclebecause, given the transmission range of cell towers, a human is notable to move the distance required to change the signal so much in sucha short period of time, whereas a cell tower whose RSSI on a devicechanges from −30 dB to −31 dB over the course of the same time isrelatively unlikely to be present within a moving vehicle because, giventhe transmission range of (most) cell towers, a device present within amoving vehicle is likely to perceive a relatively much larger change inthe strength of the signal received than 1 dB, even over a relativelyshort period of time.

It should be noted that accuracy of the referencedin-vehicle/not-in-vehicle determination(s) can be further improved whenperformed in conjunction with other connectivity/“network visibility”information/determinations (e.g., in relation to BT devices, cellularIDs, cellular RSSIs, etc.) and/or from other sensors as describedherein.

In another implementation, the conditions pursuant to which a device canbe determined to be present within a moving vehicle can be dynamicallydetermined, such as based on the device's environment, such as can bemeasured/determined by its sensors. For example, if many different WiFiaccess points (e.g., having different BSSIDs), many cell tower IDs(CIDs), and/or many Bluetooth devices are perceptible to a device,and/or if a GPS so indicates, it can be determined that the device isrelatively likely to be present in an urban area, whereas if relativelyfew (or none) of the referenced wireless signals are perceptible, and/orif a GPS reading so indicates, it can be determined that the device islikely to be in a rural area, and, because vehicles generally moveslower in urban areas than they do in rural areas, a threshold speed (orother conditions) at which a trip can be determined to have started (asdescribed herein) can be set/adjusted to be relatively lower in such anurban setting as compared to a rural setting, thereby enabling moreaccurately determinations in relation to contexts where/when devices arepresent within vehicles.

Not only can it be determined that, if a device is connected to anon-nomadic AP (e.g., for more than a relatively short time), it can bedetermined not to be moving, but further determinations can also beperformed. In doing so, for example, based on a determination that adevice is connected to a nomadic AP it can be further determined that itis relatively more likely the device is moving than if it were (a)connected to a non-nomadic AP, (b) connected to an AP of unknownnomadicity; and/or (c) not connected to an AP. In certainimplementations, such determinations can be premised based on anassumption/default that if a device is determined to be connected to anomadic AP, it can be determined to be is moving. Moreover, in certainimplementations, power/resources can be invested to determine, by way ofone or more other sensors (e.g., GPS, accelerometer, gyroscope, cellularradio, etc.) whether or not the device is moving.

Moreover, in certain implementations, a device determined not to be insubstantially the same location (e.g., as determined by GPS, WiFi APs,cell tower IDs, Bluetooth devices, IP address) (i) at or about the timeit connected to an AP as it is determined to be (ii) at or about thetime that the device disconnected from the same AP, can be determined tobe connected to a nomadic AP. Moreover, in certain implementations,irrespective of whether or not a device is determined to be atsubstantially the same location (i) at the time it connected to an AP asit was (ii) at the time that it disconnected from the same AP, thenomadicity of such an AP can be determined, for example, via GPS, suchas by comparing (i) the GPS coordinates of the referenced device'slocation at or about the time that the device connected to the WiFi APwith (ii) the GPS coordinates of the device's location at or about thetime of the device's disconnection from the same WiFi AP. By way offurther example, the nomadicity of such an AP can be determined, forexample via WiFi, such as by comparing (i) one or more of the WiFi APsperceptible at the device at or about the time of the device'sconnection to one of the WiFi APs with (ii) one or more of the WiFi APsperceptible at the device at or about the time of the device'sdisconnection from the same WiFi AP. By way of further example, thenomadicity of such an AP can be determined, for example via Cell TowerID, such as by comparing (i) the cell tower to which the device isconnected (or more or more of the visible cell towers) at or about thetime of the device's connection to the WiFi AP with (ii) the connectedcell tower (or one or more sets of the perceptible cell towers) at orabout the time of the device's disconnection from the same WiFi AP. Byway of further example, the nomadicity of such an AP can be determined,for example via Bluetooth, such as by comparing (i) one or more ofperceptible Bluetooth devices at or about the time of the device'sconnection to the WiFi AP with (ii) one or more of the visible Bluetoothdevices at or about the time of the device's disconnection from the sameWiFi AP. By way of further example, the nomadicity of such an AP can bedetermined, for example via IP address, such as by comparing (i) the IPaddress of the device shortly before the time of the device's connectionto the WiFi AP with (ii) the IP address of the device shortlyafter/about the time of the device's disconnection from the same WiFiAP.

In addition to, or instead of, the previously described technique(s)(which encompass techniques for determining nomadic WiFi APs), a WiFi APcan be determined to be non-nomadic based on a determination that thelocation of the connected device at the time it was connected to the APis substantially the same as its location at the time that itdisconnected from the same AP.

In addition, the longer (shorter) the period of time between theconnection and the disconnection (or the length of time that the deviceremains connected without disconnecting), such as in the abovereferenced scenarios, the greater the likelihood that the AP that thedevice was connected to was non-nomadic (nomadic). For example, a devicedetermined to be continuously connected to an AP for 10 hours can bedetermined, on average, to be relatively more likely to be connected toa non-nomadic AP than a device determined to be connected to an AP foronly 10 seconds.

It should be noted that the notion/concept/aspect of a ‘substantiallysame’ location (as referenced herein) can be determined, for example,relative to the transmission range of an AP. For example, it can beappreciated that certain APs can have a relatively wide transmissionrange (e.g., a WiMax AP), and in such a case it is possible that, eventhough the location at the time of connection and the location at thetime of disconnection may be determined to be relatively far apart, theAP is actually non-nomadic. As such, in one implementation, thetechniques described herein can be further configured to account for theAP's transmission range(s), as can be identified/determined, forexample, from/based on the BSSID, manufacturer, etc., of the AP, and/oras can be determined from repetitive crowd-sourcedconnection/disconnection locations, such as using one or more of thetechniques described herein. Using such techniques, WiFi APs can bedetermined to be nomadic or non-nomadic using “crowd-sourcing”techniques. For example, message(s) can be sent from user devices to aserver indicating (a) time, (b) conditions (pertaining to GPS, WiFi,cellular, Bluetooth, IP addresses, etc.) at or near the time ofconnection to the WiFi AP, and (c) conditions at or near the time ofdisconnection from the WiFi AP. It should be noted that, in certainimplementations, devices can also maintain and updatenomadic/non-nomadic AP information locally.

It should be noted that similar/related techniques can be employed inorder to determine whether other transmitters (e.g., Bluetooth devices,cellular stations, etc., and others currently existing or to beintroduced in the future) are nomadic or non-nomadic.

In certain implementations, the state of the device's display screen,keyboard and/or the presence of a device user (as determined, forexample, based on an absence/removal of a key-guard/lock on theinterface of the device, proximity sensed, etc.) can be used todetermine whether and/or how intensively (e.g., based on sampling rate,duty cycle, how much power can be consumed, etc.) device resourcesshould be used to determine the context of the device (e.g., todetermine if the device is present within a moving vehicle, determinethe in-vehicle role of its user, etc.), and/or to provide otherfunctionality, with or without taking into account the device's batterylevel, rate of battery level depletion, etc.

For example, if the device display screen is determined to be off(and/or applications with which the user can interact or receiveinformation from even when the device screen is off (e.g., an alreadyconnected call) can be determined not to be running or are restrictingthe application from providing such functionality), the powerconsumption of the device can be reduced (in light of the fact that thedevice, in its current state, cannot serve as a distraction to a driver)by reducing or eliminating some or all of its energy intensiveoperations (e.g., GPS calls) such as those used to make contextdeterminations (e.g., in-trip determinations, in-vehicle roledeterminations), as described herein. For example, upon determining thatthe screen is off, the GPS can be queried once every 5 seconds (or notat all), while when the screen is on, the GPS can be queried once persecond.

In one implementation, the device can be configured to maintain itselfin a low power consumption state in which much of, or substantially allof, the device's context information gathering can be suspended for aslong as the screen is off. Such techniques can be advantageous inscenarios where the context of the device can be promptly determinedwhen the screen is turned on (or a user is present). For example, onemanner in which this can be done is by turning the GPS on upondetermining that the screen is turned on. The latency associated withsuch a technique can be reduced by not turning the GPS radio fully offwhen the screen turns off, or by maintaining/“remembering” certaininformation that can that reduce the TTFF (time to first fix) of the GPSradio when it is next turned on, such as is known to those of ordinaryskill in the art.

By way of further example, successive scans of available/perceptiblenetworks/devices (WiFi, BT, Cell, etc.) can be performed (e.g.periodically) and the results maintained/recorded. Upon determining thatthe screen is turned on, the scan results just prior to and just afterthe device screen is turned on can be processed/used to determinewhether or not the device is in motion (and can also be processed/usedto determine/estimate the speed at which the device is moving).Moreover, the accuracy of the referenced technique can be improved bymonitoring (e.g., with a relatively low power consumption, such as at alow duty cycle) and thereby determining in advance which of the varioustechniques are likely to be useful/effective/accurate, in light of thedetermined context of the device. For example, the device cantest/determined, at various intervals while the screen is determined tobe off, whether the described Wifi scan technique is likely to beapplicable/accurate within the area in which the device is present(e.g., rural vs. urban). If it is determined that the referenced Wifiscan technique is not likely to be effective/available, it can bedetermined that another technique (e.g., one entailing higher energyexpenditure) may be required in order to accurately determine thecontext of the device (and can be employed, for example, when the screenis turned on), or it may choose to suspend the use of determinationsbased on screen state altogether, e.g., until WiFi scans can providerelevant/accurate information again.

In another implementation, a determination that a device is connected toa power source can further indicate the hands-free state and/orin-vehicle location of the device. For example, in a scenario where apassenger is present in a car, a device determined to be connected to apower source can be determined to (a) be relatively more likely to beoperated by a driver than by a passenger (because a vehicle is morelikely to have a power connection that is compatible with respect todevice operated by a driver than a device operated by a passenger, and(b) is relatively more likely to be positioned in close proximity to adriver than a passenger (in light of the near-driver location of somepower sources, e.g., a device cradle/dock having a power connection).

In another implementation, based on a determination that a device iscontinuously (or substantially continuously) connected to a power sourcesince before (or sufficiently soon after) it was last disconnected froma WiFi connection/AP (nomadic or non-nomadic), the device can bedetermined to be in the same location/context (e.g., within a vehicle,not within a vehicle, etc.) in which it was in when it was lastconnected to Wifi. In certain implementations, the accuracy of suchtechniques can be improved so that the device's current location and/orcontext can be determined based on the location and/or contextdetermined at the time that the last WiFi access point disconnected,based upon whether the WiFi access point is nomadic or non-nomadic. Forexample, in a scenario where the last WiFi access point to which thedevice was connected was determined to be a non-nomadic access point,the location of the device and its context (e.g., barring otherfactors/information) can be determined to be unchanged, whereas upondetermining that the last WiFi access point to which the device wasconnected was a nomadic access point, then, (barring otherfactors/information), its context (e.g., within vehicle) can bedetermined to be unchanged, while its location cannot. In certainimplementations, the accuracy of this technique can be further improvedby providing for/requiring that the device has be determined to becontinuously (or substantially continuously) connected to a power sourceat least a certain amount of time before it was last disconnected from aWiFi connection (in doing so, a use case where a user left his home andgot into his car in the driveway while still within range of her homeWiFi and connected the device to a power source in the car before losingconnection with the home Wifi can be addressed).

In the implementation described it is noted that a given wireless IDthat the mobile device connects to may “fool” the detection system atmost once in most cases. Once the mobile device connects to a wirelessdevice (e.g., WiFi AP, Bluetooth speakerphone) in one location anddisconnects from such device in a substantially different location, thewireless device will be marked as nomadic and future connections to itwill not be understood to indicate that the mobile device is stationary(or even be used to determine that it is not stationary).

Applicants further note that the notion of checking the location of amobile device when it is connected and subsequently disconnected from awireless device is not the only method of classifying wireless devicesas nomadic or non-nomadic. The mobile device's current location can bequeried actively to aid in classifying the wireless device as nomadic ornon-nomadic or, to save power, changes to the mobile device's “last knowlocation” can be used to accomplish the same, i.e., if the mobiledevice's last know location changes sufficiently (not sufficiently)while the mobile device is connected to a wireless device, then thewireless device is classified as nomadic (non-nomadic).

In another implementation, the presence of nomadic wireless devices(e.g., nomadic WiFi APs, nomadic Bluetooth devices) can be used todetect that a mobile device is in a trip more effectively, both (i) ifthe mobile device is connected to one or more nomadic wireless devices;and/or (ii) if the mobile device sees one or more nomadic wirelessdevices (or even certain types of nomadic wireless devices as furtherclassified by their manufacturer and/or their BT major/minor class)without being connected to them.

For example, if a mobile device connects to one or more nomadic wirelessdevices (e.g., as determined from comparing with a database on thedevice or on a remote server), the mobile device may be assumed to be ina trip and apply whatever changes to the mobile device are appropriatefor a trip and/or the mobile device may choose to invest additionalpower to seek additional confirmation as to whether it is in a trip morequickly that it would ordinarily do so.

In another example, if the analysis of the results of a wireless scan ona mobile device shows the presence of, but not connection to, one ormore nomadic wireless devices (e.g., as determined from comparing with adatabase on the device or on a remote server), the mobile device maychoose to invest additional power to determine whether it is in a tripmore quickly that it would ordinarily do so.

It can be appreciated that, in certain implementations, based on adetermination that a device is in one location at the time it connectsto an access point and in a substantially different/distant locationwhen it disconnects from the access point, then, in addition todetermining that the referenced access point is nomadic (such as in amanner described herein), it can also be determined that the external IPaddress to which the access point was/is connected or otherwiseassociated is also nomadic. Accordingly, even in a scenario in whichanother access point or device is connected to such an external IPaddress, it can be determined that such an access point/device isnomadic (e.g., even without determining/identify movement/traveling withrespect to that device/access point).

In another implementation, if a device is determined to be connected toa power source during the time that it has been determined to be in atrip, then, for as long as the device remains connected to such powersource (or an alternative power source, provided, for example, that thedevice is not unplugged from power for more than a certain period oftime, e.g., the time it might take someone to switch between a vehiclepower source and an office or home power source), it can be determinedthat the device is highly likely to still be within a trip. In sodetermining, many of the power expensive/intensive operations that mayotherwise be utilized by the device to determine the context of thedevice can be curtailed/suspended (e.g., checking GPS to see if thedevice is still present within a trip).

To the extent that the characteristics of the power source can bedetermined pursuant to the techniques described herein (or elsewhere),the determination as to whether the device is still connected to powerin a vehicle can be made relatively more easily/efficiently.

In addition, when a device is determined to be connected to power, andit is nonetheless determined that it should periodically re-detectwhether the device is in a trip or not, the efficiency of suchre-detection can also be improved (and can consume less power) becausedifferentiation between moving in a vehicle and certain other states(e.g., walking) which are highly unlikely when the device is connectedto power, may no longer be necessary.

In another implementation, upon determining that a device is presentwithin a trip and connected to a power source, it can be advantageous todetermine that a trip has ended so that, upon determining that a triphas ended, the device can be used by a user (i.e., without restriction)without having to disconnect the device from the power source (e.g., ina scenario where the vehicle is parked in a parking lot at the end of atrip with the device still being connected to power, and the user maywant to send a text). This can be achieved, for example, by sampling oneor more of a number of sensors and/or inputs (e.g., GPS, accelerometer,Win BSSIDs and/or RSSI, Cell Tower IDs and/or RSSI, BT BSSID and/orRSSIs) to determine if the device is in motion. In certainimplementations, such sensors/inputs can be sampled at sampling ratesrelatively lower than would be used if the power connection was notavailable and/or used to make contextual determinations (therebyreducing power consumption). Further, the sensors/inputs can also besampled at duty cycles relatively lower than those that would be used ifthe power connection was not available and/or used to make contextualdeterminations, thereby reducing power consumption.

It should be noted that the techniques described herein with respect toreducing power consumption are still applicable in scenarios in whichthe device is connected to a power source because, for example, if adevice battery is not near full and the time the device is presentwithin a vehicle is the only time a user has to charge the device, thenbeing able to give the battery the best charge possible (i.e., byreducing power consuming activities) can be advantageous.

FIG. 69 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 6910, one or more devices can be identified. In certainimplementations, such devices (e.g., mobile devices, wireless accesspoints, etc.) that are identified are those that are perceptible to adevice (e.g., a smartphone, mobile device, etc.). Moreover, in certainimplementations the referenced devices (e.g., those that are identified)may be being associated with a vehicle (e.g., determined to be and/orotherwise identified as being embedded, installed, or otherwise presentwith a vehicle). Moreover, in certain implementations the referenceddevice may be determined to be and/or otherwise associated with anoperator of the vehicle (e.g., a driver).

At 6920, a restriction can be employed. In certain implementations, sucha restriction can be employed with respect to the device (e.g., thedevice that perceived the various other devices/access points, such asat 6910). Moreover, in certain implementations such a restriction can beemployed based on a perception of the one or more devices. Moreover, incertain implementations such a restriction may be employed upondetermining or otherwise identifying that the device (e.g., the devicethat perceived the various other devices/access points, such as at 6910)is moving in a manner that is consistent with the manner in which avehicle moves, such as in a manner described herein. Moreover, incertain implementations, upon determining that the vehicle is not movingin such a manner, the referenced restrictions can be adjusted, relaxed,removed, etc.

By way of further illustration, it can be appreciated that distracteddriving in mass transportation contexts (such as by the driver/operatorof a bus, train, etc.) can be incredibly dangerous because an error indriver judgment can kill or injure many people. Accordingly, in certainimplementations and as described herein, the mobile device associatedwith/determined to be operated by a mass transportation driver can beconfigured to go into ‘driver mode’ (such as is described herein) basedon a perception of one or more signals (e.g., RF signals such as WiFiaccess points a Bluetooth BSSIDs, etc.) in a set of signals. Forexample, the mobile device of a bus drivers can be configured to go into‘driver mode’ upon perceiving the MAC address(es)/BSSID(s) of the WiFiaccess points or Bluetooth devices that are associated with the bus(es)that they drive, and, in some cases, when additional conditions (e.g.,movement consistent with driving) are also determined to be met. Doingso can provide various advantages, improvements and efficiencies, suchas with respect to the accuracy, latency and power consumption ofapplications/modules that are directed to identifying/preventingdistracted driving (whether executing the device itself and/orexternally to the device, such as on a remote server). In addition, suchtechniques enable the restriction of the mobile devices of masstransportation drivers while they are working (e.g., driving a bus),while also not restricting the same devices in scenarios in which thebus driver is not currently driving (it should be understood that suchtechniques can be further enhanced as more and more vehicles have uniquewireless electronic IDs) and without having to integrate with the buscompany's employee time scheduling systems.

FIG. 68 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 6810, a positioning of a device (e.g., a mobile device, smartphone,etc.) can be determined. In certain implementations, the referencedpositioning can include an orientation of the device (e.g., the angle atwhich the device is oriented, such as is describe herein) and/or adocking or connectivity status of the device (e.g., whether or not thedevice is connected to a dock or charger, whether or not the device isconnected or linked to an in-vehicle ‘infotainment’ system, etc.).Moreover, in certain implementations it can be determined that thereferenced device is present within a vehicle (and/or a moving vehicle)and/or within a trip, such as using one or more of the techniquesdescribed herein.

At 6820, one or more restricted functions can be enabled. In certainimplementations, such functions can be enabled at/in relation to thedevice. Moreover, in certain implementations such restricted functionscan be enabled based on a determination that the positioning (such asthat determined at 6810) is consistent with one or more positioningparameters. Examples of such positioning parameters can be one or moreparameters (and/or ranges thereof) that can be defined, such as withrespect to the orientation of the device, the docking connectivity ofthe device, etc. Moreover, in certain implementations the referencedrestricted functions can include one or more applications and/or one ormore interfaces.

At 6830, the referenced restricted functions can be restricted at/inrelation to the device. In certain implementations such restrictedfunctions can be restricted based on a determination that thepositioning of the device is not consistent with the one or morepositioning parameters (such as in a manner described herein).

By way of further illustration, in certain implementations certaindevice functionality (e.g., the ability to make utilize, or otherwiseinteract with calls, texts, applications etc.), such as on a devicedetermined to be associated with a driver of a vehicle can be restrictedin a manner that such functionality is only permitted when variousconditions can be determined to be met. For example, certainfunctionality (e.g., the initialization/use of a navigation application)may only be allowed when the device is determined to be positioned in acradle (as can be determined, for example, based on inputs originatingfrom one or more sensors, such as accelerometer, compass/magnetometer,GPS, camera, orientation envelope, correlation between z-axisacceleration and GPS acceleration, etc., such as is described herein,and/or based on inputs/information received from a device cradle (e.g.power connection identifier, NFC, etc.) which may be used to confirmthat the device is in it, such as in a manner described herein. By wayof further example, one or more other functionalities (e.g., the use ofa music application) may also be restricted such that the use of the arepermitted when the device can be determined to be connected to avehicle's infotainment system (as can be determined based on the wiredor wireless connection between the device and the vehicle's infotainmentsystem, such as in a manner described herein).

Moreover, in certain implementations one or more of the interfaces thatmay be used to control various functionalities of the device (e.g., atouch interface, etc.) can be selectively (or fully) restricted. Forexample, a device determined to be operated by/associated with a driverof a vehicle (such as in a manner described herein) may be restrictedsuch that a particular interface of the device (e.g., touch/touchscreeninterface) may not be allowed and/or that such an interface may berestricted with respect to a particular application (e.g., the drivermay not be allowed to input a destination in a navigation applicationusing the touch interface), while one or more other interface(s) (e.g.,a voice recognition/command interface) may still be available for thedriver to use (or vice versa).

Once the device is determined to no longer be connected to a powersource for a sufficiently long period of time, the techniques describedherein can be employed to determine if the device is still within a tripor not.

In additional implementations, the techniques described herein canaccount for whether the device is connected to a powers source, thedevice's current battery level and/or rate of battery level depletion,etc., in selecting which contextual determination techniques to useand/or how to use them (e.g., in relation to sampling rate, duty cycle,etc.). For example, upon determining that a device battery is fully ormostly charged, sensors can be sampled more liberally, whereas upondetermining that the device battery is low, sensors can be sampled on amore limited basis/more frugally. For example, when a device isdetermined to be connected to a power source, its GPS can be sampledmore frequently, whereas upon determining that the device is notconnected to a power source, its GPS can be sampled relatively lessfrequently (or not at all). Such techniques can also beemployed/extended to other sensor(s), e.g., accelerometer, WiFi scans,Cell tower scans etc.

In certain cases, it may be advantageous to use some combination of thetechniques described herein to improve the context determinationaccuracy and/or the associated power consumption.

Many of the context determinations described herein that employtechniques to use information in or related to network signals (e.g.,WiFi access points, BT Device and cell towers) can be improved withbetter/more accurate information as to the magnitude of the powertransmission of such signals. For example, for the power transmissionlevel at which a WiFi access point, a BT device or a cell tower emitteda signal can be used to determine/estimate speed more accurately. Basedon the fact that, for example, the RSSI of a BT device that transmits at2.5 mw (Class 2) has changed from −90 dB to −80 DB in 1 sec., it can bedetermined that the device is moving more slowly (relative to the BTdevice) than if the BT device transmits at 100 mw (Class 1).

In certain implementations, a device can allow simultaneous connectionto one or more networks of the same and/or different technologies. Thetechniques described herein can be adapted to such settings (e.g.,various voting techniques) using methods known to those skilled in theart.

In any/all of the techniques described herein, it may be advantageous toincorporate a “healing” mechanism whereby periodically checks can beperformed to determine/confirm that erroneous determinations have notbeen made (and/or that the device is operating in an incorrect state).For example, even when a device is connected to a power sourcecontinuously since a sufficiently long time before the last time it waslast disconnected to WiFi, the device can be periodically checked (e.g.,at a lower sampling rate/duty cycle than it might otherwise be checkedat) to further determine that it is not in a trip.

One or more of the techniques described herein can be implemented in anAPI that can be used by other applications running on/in relation to thedevice to provide such applications with accurate context information ina manner that is power efficient for the device. For example, anavigation application that wants to prevent a driver from thedistraction of inputting a destination while driving but wants to permita passenger to do so, can query such an API as to whether the device is(a) present within a trip and/or (b) is being operated by a driver or apassenger. By way of further example, using such an API, a navigationapplication (e.g., Waze) can be configured to turn itself on or offautomatically (with or without giving the user a chance to override),based on whether the device is determined to be within a trip or not(and the device can expend relatively little power to so determine). Inanother example, a telephony application (native or otherwise, e.g.,Viber, Skype, etc.) and/or a texting application (native or otherwise,e.g., WhatsApp) running on the device can determine whether or not toallow incoming and/or outgoing calls based upon the in-trip anddriver/passenger information/determination(s), as can be provided by thereferenced API.

In certain implementations, one or more aspects of thetechniques/technologies described herein can be configured in relationto a determination of a likelihood that a user associated with a deviceis going to be in a trip. It should be understood that such a likelihoodcan, for example be determined/estimated based on one or more inputs,factors, data elements, etc. (e.g., time, location, calendarinformation, user history, user or supervisor preference for tradeoffbetween latency, accuracy and power, etc.), such as those that maypertain to all users in a given population, pertain only to a segment ofsuch users (e.g., sex, demographic, location), and/or or pertain to aparticular individual user (e.g., calendar information, historical userbehavior, etc.). For example, based one or more determinations (such asthose corresponding to a particular context, as computed, for example,based on one or more on the referenced inputs, factors, data elements,etc.) relatively more resources (e.g., battery power, processing power,sensors, etc.) can be employed, activated, and/or otherwise dedicatedtowards one or more determinations pertaining to whether a user is/wasperforming a certain activity (e.g., present/traveling within a movingvehicle) during or near rush hour (as determined based on data pertinentto an entire population), during or near the time children aredriving/being driven/traveling to school within a certain neighborhood(as determined based on data pertinent to a particular populationsegment) and/or before a meeting scheduled within the user's calendar(as determined based on data pertinent to the individual user)—in orderto determine/identify such activity more accurately (by utilizing theadditional resources referenced above) and/or with less latency, withrespect to one or more of the referenced context(s). Moreover, acomparable configuration can also be employed to enable theusage/expenditure of relatively fewer resources in other context(s) todetermine whether the same user was performing such an activity at atime when (s)he can be determined to be relatively less likely to do so,e.g., in a moving vehicle in the middle of the night.

It should also be noted that, as noted above in detail with respect toFIG. 5, in certain arrangements, the processor 110 executing one or moreof software modules 130, including, preferably, determination module170, can transform an operation state of mobile device 105 based inwhole or in part on the one or more determination factor(s), such as theprobability computed at step 630. This operation can be furtherappreciated when employed in conjunction with a determination of anin-vehicle role of a user of mobile device 105, such as that depicted inFIGS. 2A-C and described in detail above. For example, in certainarrangements, upon determining (preferably to a certain minimumprobability) that a mobile device 105 is under the control of a driverof a vehicle (such as by processing the inputs from accelerometer 145Aand gyroscope 145B of mobile device 105 against those of other mobiledevices 160 within the same vehicle, thereby identifying the driver ofthe vehicle, as described in detail herein), it can then be furtherdetermined whether mobile device 105, which has been determined to beunder the control of a driver, is being operated in a handheld state(generally prohibited in most places) or in a non-handheld state(generally permitted). Accordingly, in such an arrangement (where mobiledevice 105 has been determined to be under the control of a driver andis being used in a handheld state), a transformation (substantiallysimilar to that described in detail above with respect to step 240) canbe employed In such a scenario, processor 110 can coordinate varioustransformations and/or adjustments to the operation(s) of mobile device105, as described in detail above with respect to step 240. As alsonoted above, in certain arrangements various of the referencedtransformations can be employed only when either one or both of theprobabilities pertaining to the user role of the user of mobile device105 is a driver and/or the handheld state of mobile device 105 ishandheld meet and/or exceed a certain minimum threshold.

Moreover, in certain implementations, a mobile device 105 that ispositioned in a cradle or dock (whether a ‘dumb’ cradle that simplyholds a device or a ‘smart’ cradle that provides power and/or otherconnectivity to a device) that has not already been authenticated to beoperated by a user that is a passenger (such as in the manner describedin detail herein) can be configured to employ a particular restrictionand/or set of restrictions (such as those described in detail herein)thereto, such restriction/set of restrictions preferably being differentthan restrictions that are employed at a device that has also not beenauthenticated as being operated by a passenger but is not in a cradle.Being that positioning a device in a cradle entails some degree ofadditional safety in relation to operation of the device on the part ofthe driver (being that the driver is not holding the device in his/herhand), in addition to the fact that in certain jurisdictions it ispermitted to operate mobile devices in certain manners when positionedin a cradle, it can be appreciated that in certain implementations, itcan be preferable to implement restrictions that account for thesefactors. For example, in such a scenario a cradled device can beemployed with a restriction that still allows the user to make and/or toreceive calls in geographic locations (e.g., a particular state orcountry) that allow the use of hands-free devices for calling, whereas acomparable non-cradled device can be restricted from even making suchcalls. It can be further appreciated that in certain implementations,such restriction(s) (and/or any of the other restrictions referencedherein) can be employed, for example, on/at the mobile device, on theSIM card, and/or by the cellular carrier (that is, in relation to themobile device).

In another implementation, the manner in which a device is beingheld/oriented (e.g., placed in a dock/cradle, hand-held, etc.) can bedetermined based on a spectral analysis of the frequenciesperceived/observed by the accelerometer and/or gyroscope of a device,such as in a manner known to those of ordinary skill in the art. Forexample, the spectral pattern perceived by the sensors of a handhelddevice (i.e., a device being held in the hand of a user) is likely to beidentifiably different from that perceived with respect to a device thatis placed in a dock/cradle, in that a handheld device will oftenperceive higher values (e.g., in a range of 3-7 hz).

In another implementation, the manner in which a device is beingheld/oriented (e.g., placed in a dock/cradle, hand-held, etc.) can bedetermined based on the orientation of the device (for example, as canbe measured based on inputs originating at the accelerometer,magnetometer, and/or GPS of the device, such as in the manner describedherein), in conjunction with a spectral analysis of theobserved/perceived frequencies (such as of the accelerometer and/orgyroscope), as described herein.

It should also be noted that the referenced processing/determining of anorientation of a device based on inputs originating from theaccelerometer of the device can encounter noise/interference when suchdeterminations occur within a running or ignited vehicle (i.e., avehicle having a running engine), as, for example, a running vehicle canimpart various forces that are perceptible to the device and/or thesensors of the device and which can cause anaccelerometer-measured/determined orientation to change, despite thefact that the actual orientation of the device may not change. Forexample, a device that is cradled/docked or otherwise held in an‘upright’ orientation will generally demonstrate no acceleration on itsX and Z axes, while demonstrating an acceleration of 1 g on its Y axis,and the angle of the device, as determined from the accelerometers ofthe device, is 90 degrees. Accordingly, in a scenario where the vehicleaccelerates at 1 g, and the device is oriented such that suchaccelerations are imparted on the Z-axis of the device, then theacceleration perceived on the Y and Z axes are each 1 g and the pitchangle of the device (as determined based on the trigonometricrelationship between the acceleration of its axis) is 45 degrees—whereasthe actual pitch angle of the device is 90 degrees.

Accordingly, in certain implementations, one or more inputs originatingat one or more sensors of a device can be used to filter out the noiseintroduced by vehicle acceleration events (as opposed to device-specificacceleration events). In doing so, the accuracy of the variousdeterminations with respect to the orientation of the device can beincreased/improved. For example, one or more accelerationevents/instances can be detected/identified, such as using one or moreother sensors, such as GPS, on-board car sensors, radio (e.g. Doppler,RSSI, cellular towers, Win, etc.), server-side techniques (e.g., OAO,TDOA), etc., which can be used to process the data originating from theaccelerometer and/or gyroscope of the device in an improved/moreaccurate manner. By way of illustration, In the referenced example, theGPS sensor of the device can measure/identify a change in speed of thevehicle that can be consistent with the referenced 1 g forwardacceleration, and it can be determined that the 1 g accelerationobserved with respect to the Z-axis of the accelerometer was present dueto the acceleration of the vehicle and not from a change in the actualorientation of the device, and, as such, it can be further determinedthat the actual pitch angle of the device remains 90 degrees (and not 45degrees).

It should also be appreciated that in certain implementations, one ormore restrictions can be employed at/in relation to a mobile device,based on a geographical determination, as referenced above. That is, inlight of differences in laws regulating mobile device usage by driversin difference jurisdictions, one or more restrictions can be selectivelyemployed at a mobile device based on a determination of the location ofthe device (e.g., based on inputs received from the GPS). Thus, in ascenario where State A prohibits texting while driving, while State Bprohibits texting while driving and talking while driving, theappropriate corresponding restriction (effectively preventing/precludingthe mobile device from performing the prohibited operation) can beemployed based on the location of the mobile device (as determined bythe GPS, cell towers and/or wifi transceivers seen/detected, as is knownto those of ordinary skill in the art).

In certain implementations, a device can be determined to be positionedin a cradle or dock based on the level of movement of the device. Forexample, a device that is held in a cradle will tend to move less than adevice that is not held fixed in a cradle—as can be determined based onan analysis of inputs originating at the accelerometer and/or gyroscopeof the device, and, for example, the tightness (e.g., standarddeviation) of the distribution of accelerometer readings or changesthereto, such as in a manner described herein and known to those ofordinary skill in the art.

In other implementations, the orientation of the device can be used todetermine if a device is in a cradle or not. For example, a device thatis in a cradle will have a fixed and known orientation (e.g., generallythe y-axis accelerometer, as shown in FIG. 9A) will pick-up a largecomponent of gravity and/or the X-axis accelerometer will pick up alarge component of gravity, as can be appreciated by those of ordinaryskill in the art.

In certain implementations, the presence/existence of connections to thedevice (‘smart’ cradles supply power and/or connectivity to the device)can be used to determine if a device is in a cradle or not.

In yet other implementations, the orientation of a device relative tothe vehicle in which it is present can be used to determine if thedevice is in a cradle or not. If such orientation is fixed over sometime period, then it can be determined that the device is fixed (e.g.,is positioned in a cradle/dock). If such orientation is not fixed (e.g.,the device is actually hand-held), then it can be determined that thedevice is not in a cradle. For example, the orientation of the devicerelative to the vehicle can be determined at any point in time using (a)the device's GPS bearing, which measures the direction of movement ofthe device with respect to the Earth (denoted G), regardless of theorientation of the device within the vehicle; and (b) the device'smagnetometer/compass, which measures the orientation of the device withrespect to the Earth's magnetic field (denoted M), which depends on theorientation of the device in the vehicle and the bearing of the vehicle.For a device whose orientation with respect to the vehicle is fixed(e.g., a device in a cradle), a constant rotation matrix, R, can befound/computed, such that G*R=M, such as in a manner known to those ofordinary skill in the art. However, for a device whose orientation withrespect to the vehicle is not fixed (e.g., a hand-held device), suchrotation matrix is not constant.

It should also be understood that the identification of a device asbeing in a cradle/dock, as referred to herein, can beconfigured/expanded to any device whose position relative to thevehicle's is static and/or any device that is not hand-held.

Various of the referenced implementations and functionalities relatingto the cradle/dock status of the mobile device are described in greaterdetail below, specifically with respect to FIG. 24.

Turning now to FIG. 7, a flow diagram is described showing a routine 700that illustrates a broad aspect of a method restricting operation of amobile device 105 in accordance with at least one embodiment disclosedherein. As will be described in greater detail below, various of thesteps and operations that make up routine 700 share substantialsimilarities to those described above in connection with FIGS. 2A-C, 3,4, 5, and 6. It should be noted at the outset that while the followingdescription of routing 700 will be directed primarily to operationsoccurring at mobile device 105, such description is exemplary andintended for the sake of clarity and consistency. However, it should beunderstood that any and/or all of the steps in routine 700 can besimilarly employed at another device/machine, such as at central machine168, such as in the manner described in detail above with respect toFIG. 4. Furthermore, the same principle should be understood andappreciated with respect to any and all of the various steps,operations, and/or functions described throughout the presentdisclosure. That is, while any one of the particular steps, operations,and/or functions are described herein as being performed at and/or upona particular machine or device (such as mobile device 105, mobile device160, and/or central machine 168), such description should be understoodas being exemplary and/or illustrative and not limiting. Accordingly, itcan be appreciated that any and all steps, operations, and/or functionsdescribed herein with regard to a particular device and/or machine (suchas mobile device 105) should be similarly understood to be similarlycapably of employment at another device and/or machine (such as centralmachine 168), substantially in the manner described herein, withoutdeparting from the scope of the present disclosure.

At step 701, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 determines whethermobile device 105 is present with a vehicle, such as through one or moreof the various determination methods described in detail herein.

Upon determining the mobile device 105 is within a vehicle (such as acar, a truck, a van, a motorcycle and a jeep), at step 703, processor110 executing one or more of software modules 130, including,preferably, restriction module 171 determines whether the vehicle is inmotion, such as through one or more of the various determination methodsdescribed in detail herein.

At step 705 where processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, employs afirst restriction at mobile device 105 and/or in relation to mobiledevice 105. As will be described in greater detail herein, the firstrestriction is preferably one or more instructions that dictate at leastone operation state of the mobile device. Examples of such restrictionsinclude but are not limited to: instructions that disable a particularfeature or functionality of a mobile device 105 (such as the ability totype text), instructions that disable multiple features orfunctionalities of a mobile device 105 (such as the ability to launchcertain applications and the ability to receive text messages), andinstructions that functionally “lock” mobile device 105 by effectivelydisabling many or all of the functionalities of the device. It should beunderstood that in many arrangements, the referenced first restrictionis preferably a default restriction. That is, in such arrangements thefirst restriction is employed by default, such as upon powering onand/or activating mobile device 105. It should be appreciated that incertain arrangements such restriction can be employed in relation tomobile device 105, such as by a central machine 168, such as in themanner disclosed in detail herein, for example with respect to FIG. 4.By way of illustration, the referenced restriction can be imposed by acommunications provided (which preferably operates central machine 168)to prevent transmission of one or more communications (e.g., SMSmessages) to a mobile device 105, until an identification/determinationis made, such as identifying that two or more users are in a vehicle,such as in the manner disclosed in detail herein.

It should be understood that in various arrangements, including many ofthose described herein, the various restrictions employed at mobiledevice 105 are directed towards configuring mobile device 105 in such amanner that operation of and/or interaction with the device isdifficult, inconvenient, and/or impossible (that is, it can be said thatoperation of mobile device 105 is impeded) for a user who is alsosimultaneously operating a vehicle. At the same time, such restrictionsare also preferably configured to create minimal, if any, difficultyand/or inconvenience when operated by and/or interacted with by a userwho is not simultaneously operating a vehicle. In other words, it can besaid that such restrictions preferably impede operation of the mobiledevice by a user who is a driver more so than they impede operation ofthe mobile device by a user who is a passenger. As such, it should befurther understood that in certain arrangements it can be preferably formobile device 105 to initially determine that the device is presentwithin a vehicle (such as through one or more of the variousdetermination methods described in detail herein) prior to employingsuch a first restriction. Accordingly, it can be further appreciatedthat the various steps and operations described herein with reference toFIGS. 7-8 can be further implemented, in certain arrangements, inconjunction with one or more of the various other methods and systemsdescribed in detail herein, such as those described with reference toFIGS. 2A-6. Furthermore, it should be recognized that any one or more ofthe various steps, operations, routines, functions, and/or figuresdisclosed herein can preferably employed in conjunction within any oneor more of the various steps, operations, routines, functions, and/orfigures disclosed herein. Thus, for example, the various restrictionsdescribed in conjunction with FIG. 7 can be employed in conjunction withthe various determination operations described above. By way of example,one or more of the referenced restrictions can be employed before theoccurrence of and/or in response to one or more of the determinationsdescribed in detail herein.

It should be understood that in various arrangements, at least one ofthe one or more restrictions that dictate the at least one operatingstate of mobile device 105 are determined based on inputs originating atleast one of the various sensors 145, etc., as described in greaterdetail herein.

At step 707, mobile device 105 preferably prompts one or more users toinitiate and/or provide one or more stimuli that can be received asinputs at mobile device 105. By way of example, mobile device 105 canprompt each of the one or more users in a vehicle to repeat a particularword or series of words projected by mobile device 105. It should beunderstood that in certain arrangements such a prompt can request forthe words to be repeated sequentially while in other arrangements such aprompt can request for the words to be repeated simultaneously, while inyet other arrangements the timing of the repetition is of noconsequence. It should be appreciated that such prompting can requestpractically any stimulus that can be received and/or analyzed as aninput in the manner described herein.

At step 710, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives at least afirst input and a second input (e.g., the referenced stimuli), in themanner disclosed in detail herein. As has already been described indetail herein, each of the first input and the second input preferablyoriginate at one or more of sensors 145, software modules 130, userinterface 172, operating system 176, and/or communication interface 150,though it should be understood that the first input and the second inputneed not originate from the same source.

It should be understood that, as referred to herein, such inputs arereferred to as originating at one or more of sensors 145, softwaremodules 130, user interface 172, operating system 176, and/orcommunication interface 150 in the sense that such inputs are initiallyperceived—from the perspective of mobile device 105—at such components.However, it should be recognized, as will be appreciated in connectionwith the following examples, that in many arrangements and scenariossuch inputs (and/or the stimuli and/or phenomena that trigger them) canultimately originate at sources other than at various components ofmobile device 105. Accordingly, it should be appreciated that within thecontext of the discussion of the subject matter encompassed by FIG. 7,various inputs are referred to as originating at a particular componentin the sense that they originate from such a component with respect tomobile device 105. However, it is acknowledge that such inputs can, inturn, have ultimate origins beyond mobile device 105 itself, such asfrom the voice of a particular user and/or from an external system ordevice, as illustrated below.

For example, a first input corresponding to the audio tones of the voiceof a first user can be received at microphone 145D, and a second inputcorresponding to the audio tones of the voice of a second user can alsobe received at microphone 145D. It should also be understood that incertain arrangements, one or more of the various inputs can be receivedat and/or originate from a source external to mobile device 105, such asvehicle data system 164 and or another mobile device 160. By way ofexample, vehicle data system 164 can provide an input to mobile device105 (preferably received via communication interface 150) indicating theweight measured on one or more seats of a vehicle, and/or the usage ofseat belts at one or more seats of a vehicle, etc.—which can in turn,indicate that more than one user is within a vehicle. By way of furtherexample, a detection of mobile device 160 within a vehicle (using one ormore of the methods described herein) can also indicate that more thanone user is within a vehicle.

At this juncture, it should be noted that while the first input and thesecond input have been described herein as being discrete inputs, suchdescription is merely exemplary and for the sake of clarity andillustration. Accordingly, while in certain arrangements the first inputand the second input are separate inputs in the conventional sense—thatis, inputs that originate at two independent sources, in otherarrangements the first input and the second input are actually aspectsfound within a single input. For example, a single audio input (such asan audio recording) that contains two distinct voices (such as thevoices of a first user and a second user) can be processed (in themanner described herein) to identify such distinct voices within thesingle audio input, which are understood to be a first input and asecond input within the context of the present disclosure.

Then, at step 720, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, analyzes thefirst input and the second input. In doing so, the presence of at leastone of two or more users and/or two or more mobile devices can bedetermined, such as a determination of the presence of a first user andthe presence of a second user, such as in the manner described in detailherein. By way of illustration, continuing with the example referencedabove at step 710, the first and second inputs (that is, the audio tonesof the voices of the first user and the second user) can be analyzed toidentify an audio signature for each of the respective inputs, in amanner known to those of ordinary skill in the art, and such audiosignatures can then be compared to determine if they are substantiallysimilar and/or identical (indicating that both inputs likely originatefrom the same source, i.e., the same user) or substantially dissimilar(indicating that each of the inputs likely originate from differentusers). Thus, upon identifying that first input (here, the voice of thefirst user) is substantially distinct from the second input (here, thevoice of the second user), it can be concluded at minimum that thedevice 105 is in the presence of (if not in close proximity to) a firstuser and a second user. Additional illustrations of such inputs todetermine the presence of at least one of two or more users and/or twoor more mobile devices are presented below at EXAMPLE 4.

Upon determining that mobile device 105 is in the presence of at leastone of (a) two or more users and/or (b) two or more mobile devices, suchas by determining the presence of at least a first user and a seconduser, at step 742 processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171 modifies anemployment of at least one restriction such as the first restriction.That is, being that a determination (at step 720) that the device is inthe presence of at least two users necessarily indicates that at leastone of such users is not a driver of a vehicle, this conclusion canpreferably trigger and/or initiate the modification of the firstrestriction. In certain arrangements, such modification can include theemployment of a second restriction, strengthening of the firstrestriction, and/or the easing of the first restriction. In onearrangement, such a second restriction can include one or moreinstructions that dictate one or more operational states of the mobiledevice 105 with respect to one or more of the various sensors 145 of thedevice. That is, as noted above, such a restriction can configure mobiledevice 105 to operate in a manner that is relativelydifficult/inconvenient for a driver while being relatively unobtrusivefor a passenger. Put differently, it can be said that such restrictionsimpeded operation of mobile device 105 by a user who is a driver more sothan the same restrictions impede operation of a mobile device 105 by auser who is a passenger. Examples of such restrictions include but arenot limited to: requiring that the device only operate in ‘landscape’mode (which generally requires two hands for efficientinteraction/navigation—a demand that is relatively simple for apassenger to comply with but relatively difficult for a driver, whoneeds at least one hand to steer the vehicle, to comply with), requiringthat the device operate only at certain orientations (as detected by oneor more of sensors 145, such as gyroscope 145B, accelerometer 145A, GPS145C, and magnetometer 145E) such as a completely upright orientationwhich is relatively simple for a passenger to comply with but which isinconvenient for a driver who will not find such an orientation ascomfortable while driving and who will generally wish to hold the deviceat alternate orientations in order to obscure the device from the viewof law enforcement officials), and that the device not operate in amanner/pattern that is consistent with that of a driver (such as thevarious in-vehicle role determinations described in detail herein). Itshould be noted that although such restrictions are generally effective,on average, in impeding operation of a device by a driver more so than apassenger, it is recognized that certain individual drivers may not findsuch restrictions particularly inconvenient, while other passengers mayfind them highly inconvenient. Nevertheless, on average, suchrestrictions impede the operation of mobile device 105 by drivers moreso that they impede such operation of mobile device by passengers.

In the event that the presence of at least one of (a) two or more usersand/or (b) two or more mobile devices, such as the presence of a firstuser and a second user, are not determined and/or one or more users notin the set of users known to be users of the mobile device, is notdetermined (at step 720), at step 744 processor 110 executing one ormore of software modules 130, including, preferably, restriction module171 maintains the employment of the first restriction.

In certain implementations, upon detecting/determining that a device ispresent/operating within a moving vehicle, one or more input methodsassociated with such a device (e.g., keyboard, voice commands, gestureinputs, etc.) can be modified or changed, such as to different inputmethod(s) that selectively restrict one or more aspects of thefunctionality the device. For example, based on adetection/determination that a device is present/operating within amoving vehicle, an on-screen keyboard can be replaced (or altered) suchthat the keyboard can only receive a single input/character during adefined time period (e.g., every 15 seconds). Alternatively, such inputmethod(s) can be selectively altered or replaced in relation toinstances during which one or more particular application(s), such asthose identified as being distracting (e.g., texting, e-mailing, webbrowsing, social networking, etc.), are executing at the device.

In another implementation, a determination can be made as to when thedevice is present/operating within a moving vehicle and, based on such adetermination, the device can initiate an operation mode that canselectively restrict one or more functionalities of the device (“DriverMode”), such as in the manner described herein.

In certain implementations, while a device or devices can be determinedto be present within a moving vehicle/trip, the voice(s) of one or moreuser(s) perceived at one or more device(s), such as while engaged in atelephone call or other such audio communication, can beprocessed/analyzed to determine, for example, whether a particularspeaker is relatively likely to be a driver or a passenger. Suchdetermination(s) can be achieved, for example, by comparing responsetime, pitch, tones, intonations, intensity, volume and other speechcharacteristics between the speaker and a reference population and/orbetween the speaker and one or more references to the speaker himself(or herself) over time, such as in one or more different situations(e.g., when not in a moving vehicle, when in a moving vehicle whendetermined to be in different roles, e.g., driver/passenger, etc.),where the context of the situations may be known and/or unknown, etc. Itshould be understood that one or more speech recognition, speakerrecognition, intonation analysis, non-verbal communication and/or voiceemotion detection including spectral analysis, waveform analysis andneural networks techniques, as are known to those of ordinary skill inthe art, can be employed in achieving such determinations. For example,one or more users can be determined to possess/exhibit certain elementsor characteristics in his (or her) voice and intonations when the useris determined to be a driver (for example, at times a driver may pausefor a relatively longer period of time before responding to a question),whereas such a user's voice doesn't possess/exhibit these elements (orpossesses/exhibits them to a different extent or with a differentfrequency) when the user is determined to be a passenger or outside avehicle.

Although some jurisdictions have legislated laws (and entities haveadopted policies) for total driver cellphone bans (for some subset ofdrivers or all drivers), other jurisdictions (and entities) allowhands-free or even handheld phone calls (while possibly blocking otherfunctions, like typing or reading emails). Even with respect to thosejurisdictions (and/or entities) who allow their drivers to conduct phonecalls while driving, it may be advantageous to configure a mobile deviceto operate/react in one or more ways when the driver/user can bedetermined to be emotionally distressed. One example of such a reactionis to configure the mobile device to give the driver an audible and/orvisual “calm down” message, another example is to end a call orotherwise “harden” or strengthen the mobile device's Driver Mode policy(e.g., by selectively implementing additional restrictions in relationto the device), until, for example, the driver can be determined to havecalmed down.

FIG. 42 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4205 a perception of one or moresignals can be identified, such as in relation to a first device. Incertain implementations, the one or more signals can originate at one ormore other devices. At 4210, a performance of one or more authenticationtechniques can be enabled, such as in relation to the first device. Incertain implementations, a performance of one or more authenticationtechniques can be enabled based on an identification of the one or moresignals in relation to the first device.

When one device is in ‘Driver Mode,’ one or more other devices (such asthose executing a comparable application capable of selectivelyrestriction a device) can project or otherwise emit or provide a signalor notification (which, in various implementations, may be audible,inaudible, via Bluetooth, etc.) (referred to herein as a “SpecialSignal”). In certain implementations, such “Special Signals” can beconfigured such that they are perceptible only by other devices presentwithin the same vehicle (as can be achieved by providing such signals ata relatively law power of transmission, such that, in most cases, thesignals are unlikely to be perceptible to devices outside of thevehicle). Moreover, such signal(s) can be provided on a continuousand/or periodic basis (whether static, e.g., once every 15 seconds, ordynamic periodicity, e.g., at randomized intervals, at randomizedfrequencies, and/or in conjunction with randomized content generated bya remote server (such as in order to prevent tampering).

Having initiated ‘Driver Mode’ with respect to a device (and/orotherwise restricted such a device) the referenced device can beconfigured (such as via the referenced ‘Driver Mode’) to enable anadjustment of such a state, such as changing/transitioning the device toanother operational state such as a passenger mode (“Passenger Mode”)based on a determination (and, in certain implementations, for as longas) that the device is capable of perceiving a ‘Special Signal’ emittedby driver device (e.g., a device determined to be operated by a driver,presumably originating from a device within the same vehicle).

In another implementation, a device operating in ‘Driver Mode’ can betransitioned to another state, such as to ‘Passenger Mode’ bysuccessfully performing one or more passenger authenticationtechnique(s), such as those described herein.

It can be appreciated that, in light of the fact that most vehicles haveonly one occupant in them, and such occupant is, by definition, thedriver, devices being operated by such solo drivers can be configured toinitiate ‘Driver Mode’ (and remain in such a state) because no ‘SpecialSignal’ is perceptible to such devices.

Moreover, in certain implementations, having initiated a ‘PassengerMode’ with respect to a device (such as in the manner described herein),such a device can be configured to cease to emit/project the referenced‘Special Signals.’

In certain implementations, information identifying the device that waspassenger authenticated (e.g., a device ID such as IMEI), a SIM ID suchas IMSI, UUID, telephone number, etc.) and/or the device that enabledsuch authentication can be collected, time-stamped, GPS-stamped, savedand/or analyzed. In addition, information pertaining to when a passengerdevice ceased to receive a Special Signal and, therefore, left PassengerMode (e.g., corresponding to a trip stopping, the driver and passengerseparating, the driver turned off his/her device, etc.) can also bestored.

In another implementation, one or more aspects of the referencedinformation collected over time can be analyzed. In doing so, instancesin which one device is used to enable another device to operate in‘passenger mode,’ and the device that enabled such operation is thenobserved to operate in a relatively limited manner (e.g., with respectto calls, texts, data sent/received, contact present or changes thereto,applications run, etc.) outside of emitting a Special Signal, can beidentified. Identifying such instances can be advantageous in order toidentify drivers who may procure one or more additional devices to“sacrifice” as driver devices so that a second device can beauthenticated as a passenger device (such as in the manner describedherein) and used freely while driving.

In another implementation, a driver having a device that does not havethe software/application capable of configuring the device toproject/emit the referenced ‘Special Signal’ may have the option to (a)download or otherwise obtain a ‘lite’ version of the software thatenables projection/emitting of such a Special Signal (thereby enablingpassengers within the vehicle to transition their devices into PassengerMode, such as in the manner described herein), (b) go to a website thatplays a Special Signal, and/or (c) receive a Special Signal over a voiceconnection (e.g., by calling a phone number that plays a SpecialSignal).

Moreover, in certain implementations device users can stop the emissionof a Special Signal from their devices. In so doing, a passenger canprevent a driver from using his/her device in Passenger Mode (orattempting to).

In public transportation settings/scenarios, the referenced SpecialSignal can be emitted by and/or amplified by hardware within thevehicle. Alternatively, other devices that perceive a Special Signal canalso relay (or “repeat”) such Special Signal, thereby increasing itseffective range of transmission.

In another implementation, a passenger device can be prompted to requestfor a driver device to emit a Special Signal, rather than have alldevices within a vehicle emitting a Special Signal until they transitioninto Passenger Mode.

Turning now to FIG. 8, a flow diagram is described showing a routine 800that illustrates a broad aspect of a method restricting operation of amobile device 105 in accordance with at least one embodiment disclosedherein. As will be described in greater detail below, various of thesteps and operations that make up routine 800 share substantialsimilarities to those described in detail herein.

At step 801, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 determines whethermobile device 105 is present with a vehicle, such as through one or moreof the various determination methods described in detail herein.

Upon determining that mobile device 105 is within a vehicle (such as acar, a truck, a van, a motorcycle and a jeep), at step 803, processor110 executing one or more of software modules 130, including,preferably, restriction module 171 determines whether the vehicle is inmotion, such as through one or more of the various determination methodsdescribed in detail herein.

At step 805, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs one or morerestrictions at mobile device 105 and/or in relation to mobile device105, substantially in the manner described above with respect to step705. It should be understood that such restriction(s) are preferablyconfigured to impede operation of mobile device 105 by a user that is adriver more so than the restriction(s) impede operation of mobile device105 by a user that is a passenger, as described in detail herein.Examples of scenarios where the operations of routine 800 can beimplemented include teenage drivers (wherein a parent/guardian wishes toemploy such restrictions, which make it difficult to operate a mobiledevice 105 while driver, at all times) and/or phones that are fixed invehicles, such as car phones (wherein it is always desirable toimplement such restrictions). It should be appreciated that in certainarrangements such restriction can be employed in relation to mobiledevice 105, such as by a central machine 168, such as in the mannerdisclosed in detail herein, for example with respect to FIG. 4. By wayof illustration, the referenced restriction can be imposed by acommunications provided (which preferably operates central machine 168)to prevent transmission of one or more communications (e.g., SMSmessages) to a mobile device 105, until an identification/determinationis made, such as identifying that two or more users are in a vehicle,such as in the manner disclosed in detail herein.

It should be further understood that in certain arrangements, suchrestriction can be further configured to impede operation of the mobiledevice, and/or be more likely to be applied to a mobile device used by adriver than to a mobile device used by a passenger. By way of example,consider a scenario where a particular restriction is employed such thatif the ‘shake’ perceived at mobile device 105 exceeds a certainthreshold level, SMS messages cannot be sent from the device. It can beappreciated that employment of such a restriction does not impededrivers more than passengers (being that, once employed, it will impedea driver and a passenger equally), however such a restriction is morelikely, on average, to be employed for drivers than for passengers(being that drivers, on average, shake their devices more thanpassengers). Further such examples are provided at EXAMPLE 4.

It should be further understood that, as described in detail above, suchrestriction(s) can be configured to be applied to a mobile device asused by a first user more so than such restrictions are applied to amobile device used by a second user. By way of example, suchrestrictions can be configured to impede a user who uses the mobiledevice in an unauthorized operation state more so than a user who usesthe mobile device in an authorized operation state. By way ofillustration, one such example, which is preferably directed topreventing students from using their mobile devices while they are in aclassroom setting, can impose a restriction such that the mobile deviceis only operable and/or functional if the device is held upright and/orat a certain altitude (as can be determined based on one or more ofsensors 145, as described in detail herein). In doing so, students willeffectively have to hold their mobile devices upright and in a certainconspicuous orientation, such that it will be very difficult for suchstudents to operate their mobile devices inconspicuously during a class,such as underneath a desk. Accordingly, it can be appreciated that sucha restriction impedes users (here, students) who use their mobiledevices in an unauthorized operation state (that is, for example, duringclass), which such a restriction does not impede users who use theirmobile devices in an authorized operation state (that is, when not inclass) to the same degree. It should be further understood that thereferenced examples and illustrations are merely exemplary, and thatmany other such restrictions within the scope of the present disclosureare similarly possible.

Additionally, a device that is located in a vehicle can be used todetermine whether the vehicle's engine is on or off. One manner in whichthis is useful, is when considering that a vehicle that has recentlystopped moving, but whose engine is still on, may likely continue itspresent trip (e.g., stopped at a red light), whereas a vehicle that hasrecently stopped moving and whose engine is off has likely finished itspresent trip. Differentiating between these two states in useful, amongother reasons, in order to know when usage restrictions on a driver'sdevice should be lifted, such as in the manner described herein.

In one implementation, the device's accelerometer and/or gyroscopeand/or magnetometer can be used to determine whether the engine isrunning or not. For example, the accelerometer and/or gyroscope and/ormagnetometer show larger movements and/or movement at differentfrequencies, when the engine is running as opposed to not running.

In another implementation, the device's microphone(s) is used todetermine whether the engine is running or not. For example, themicrophones will show signals at different frequencies, includingharmonics of the base frequency which can be more easily detected by themicrophones used on popular devices, when the engine is running than ifthe engine is not running.

In yet another implementation, the event of starting or stopping theignition can be captured by the accelerometer, gyroscope and/ormicrophone. For example, the magnitude of the acceleration at the timethe ignition is started or stopped is considerably larger than theprevious and subsequent accelerations in a stationary vehicle.

In yet another implementation that may be particularly useful forelectric vehicles, the event of starting or stopping the ignition may becaptured by the magnetometer because the magnetic field created by anelectric car will change when the car is turned on or off.

It can be appreciated that in certain situations it may be useful (a) torestrict driver devices in vehicles that are temporarily stopped, forexample at a stop light (i.e., not moving, but that have been movingrecently and whose engines are still on and/or whose ignition hasn'tbeen turned off); but (b) to not restrict device's in vehicles that werejust turned on, for example, still in their parking spot (i.e., notmoving, and were not moving recently, but whose engines has been startedrecently).

Additionally, it can be useful to measure the accelerometer readingand/or magnetometer readings across the 3-axes using anorientation-invariant, for example, using the RMS of the accelerationson each of the 3 axes or other techniques known to those of ordinaryskill in the art of signal processing and time-series analysis.

Additionally, it should be appreciated that various time parameters canbe associated with many of the above methods so as to effectivelydifferentiate between events or states that are recent and ones that arenot.

In certain implementations, one or more of the techniques describedherein can be configured to determine whether a device is (or is likelyto be) within a moving vehicle based on (a) signals that are measured bythe device itself (e.g., by the internal accelerometer) orprovided/imparted from external devices (e.g., cellular network, otherterrestrial or non-terrestrial infrastructure, the vehicle or othervehicles, WiFi networks, GPS networks) and received at the device and/or(b) signals that are provided/imparted from the device (e.g., RFcellular signals) and picked up external to the device (e.g., thecellular network, other infrastructure, the vehicle or other vehicles),such as is described herein.

In certain implementations, one or more transmitters within a vehiclecan send a signal (e.g., BT, WiFi) when (and for as long as) the vehicleis moving (or, optionally, in a lower state where it also able to move,e.g., “On” or “Not in Park”) (the “In-Vehicle Signal”). Devices can beconfigured to ‘wake up’ from time to time to ‘listen for’ the In-VehicleSignal and, when such a signal is perceived (e.g., for a long enoughperiod of time), they can be determined to be in a moving vehicle. Thedevices can be configured to ‘listen’ for this signal at somewhere intheir architecture stack (hardware, firmware, operating system,application, etc.) so as to reduce the power needed and/or provide theoption to allow such to function without the user being able to controlit (e.g., turn off or opt out).

Upon determining that a device is in a moving vehicle, the in-vehiclerole of the device user can be determined (e.g., identifying the user asa driver or passenger, and, optionally further differentiate betweenpassengers that are near to the driver and whose device use might bedistracting to her (e.g., front seat passengers) and passengers who areless near to the driver (e.g., rear-seat passengers)). In doing so, theappropriate usage rule set can be applied to such device. Such techniquecan determine the device user's in-vehicle role and/or can, for example,determine/infer the in-vehicle role of the device user based on thein-vehicle location of the device. Such determination can be performedone or more times per trip.

In certain implementations, one or more techniques for determining thein-vehicle role of a device user and the in-vehicle location of a deviceuser, such as those described herein, can be employed in conjunctionwith one or more in-vehicle transmitters (e.g., transmitters employedwithin the vehicle), such as by configuring the device to ‘listen’periodically for certain signals. In doing so, the in-vehicle locationof the device can be determined such that an in-vehicle role of thedevice user can be determined/inferred and an appropriate usage rule setcan be applied to the device.

In certain implementations, based upon a determination of/datapertaining to the location of the in-vehicle transmitter, the time thatit takes a signal emitted from the transmitter (the “Distance Signal”,which could be part of the In-Vehicle Signal in certain embodiments) toreach the mobile device can provide an indication as to the in-vehiclelocation of the device, such as in order to determine the in-vehiclerole of the device user. For example, if the time that it takes for theDistance Signal to travel from the in-vehicle transmitter to the device(the “time of flight”) is below a certain threshold (which may depend,for example, on the in-vehicle location of the transmitter, among otherthings) and the in-vehicle transmitter is placed in the vehicle'ssteering wheel, then the mobile device can be determined/inferred to bethe driver's.

In order to measure time of flight with a certain degree of accuracy, incertain implementations (a) the clock on the mobile device and the clockon the in-vehicle transmitter (or the clock in the vehicle to which itmay be connected) can be synchronized (e.g., within a certain margin oferror), and/or (b) the mobile device can be configured to determine thetime at which Distance Signal is received with sufficient resolution(i.e., accuracy) to sufficiently determine the distance between thetransmitter and the device, and/or (c) the device can be configured todifferentiate between the original Distance Signal transmitted andmyriad multipath signals that arrive at the device due to signalreflection or other indirect routes.

In the event that both the device and the vehicle have network access(and the transmitter is, for example, connected to the vehicle's LAN orhas independent access to the network) the device and the transmittercan be synchronized using existing protocols like NTP. In the event thatone or both of the sides do not have network access (e.g., because theyare in a location that does not have network connectivity or because,such connectivity is not provided/available), the two devices cansynchronize between themselves, for example, by using a signal (the“Sync Signal”, which can be part of the In-Vehicle Signal in certainembodiments) that can, for example, travel more quickly than theDistance Signal (through which the distance between the device and thetransmitter will be measured). For example, the transmitter and themobile device can synchronize by having the transmitter send a SyncSignal (e.g., an RF pulse via BT, Win etc.), once every 5 seconds, whicha device (at a distance of 70 cm) will receive approximately 2nanoseconds later (assuming that the Sync Signal travels at the speed oflight, 300,000,000 m/s). The transmitter then sends the Distance Signal(e.g., an inaudible sound pulse that can be detected by the one or moremicrophones on the device), say, 3 seconds later and the device (at adistance of 70 cm) can receive such signal about 2 milliseconds later(assuming that the Distance Signal travels at the speed of sound, 340m/s). (It is noted that the order in which the Sync Signal and theDistance Signals are discussed above is done for the ease ofexplanation, but, in various implementations, these signals can be sentsimultaneously or the Distance Signal can be sent before the SyncSignal, whereupon the in-vehicle location determination can be madeafter the timing of the Sync Signal is determined/known). Bytransmitting the Distance Signal as a pulse and using the first suchsignal received on the device during any given transmission cycle, thedifficulties of multi-pathing can be avoided. For example, a rule mightstate that, if a device receives the Distance Signal within 2 ms (e.g.,70 cm distance) of its being sent then it is determined to be a driverdevice. Otherwise (i.e., if it does not receive the Distance Signalwithin 2 ms), it is determined to be a passenger device. Signalsreceived after 2 ms and until the next Distance Signal transmission (5seconds later) can be disregarded.

Illustrative time line for example above:

t₀=Sync Signal transmitted

t₁=Distance Signal transmitted

t₂=Cutoff for Distance Signal (t₁+2 ms)

t₃=Next Sync Signal transmitted

The Sync Signal and/or the Distance Signal can be transmitted at thestrengths and in the forms such that they can be received by the mobiledevices in the vehicle with sufficient accuracy (e.g., in light ofintra-vehicle or extra-vehicle noises or interference), whereby, incertain situations, the strength or the form (e.g., frequency, duration,encoding) of the signals may be modulated to so ensure. If the vehicleis the power source of the transmitter, then this is easy from a powerstandpoint, though in some implementations, form modulations (e.g.,changes to the signal's frequency, duration or encoding) may bepreferable).

In some cases, two (or more) vehicles may be sufficiently close to oneanother such that one can ‘hear’ the signals transmitted by the other.This may be prevented or significantly minimized in various ways know tothose skilled in the art, including time-slicing. For example, if DeviceA is in Vehicle A and constantly receives Sync Signals from thetransmitter in Vehicle A approximately every 5 seconds and then VehicleB, which is travelling in close proximity to close to Vehicle A,transmits a Sync Signal that Device A receives after, say 3 seconds,from the last Sync Signal sent from Vehicle A, such a signal can bedisregarded as “crosstalk” because it was scheduled to receive its nextsignal after 5 seconds and will restrict the acceptance of signals tothose that arrive in a tight window around that at 5 seconds time (e.g.,5 seconds+/−3 ms), as legitimate Sync Signal (the probability of a SyncSignal arriving from another vehicle during such +/−3 ms window each 5seconds is about 0.1%, assuming that there is a vehicle in suchproximity whose signal can pass through from one vehicle to another). Inanother example, each device can transmit a random “identity” elementencoded within its Sync Signal that can be received by the device andused to identify if that Sync Signal should be used (i.e., if it wasreceived from the correct in-vehicle transmitter) or ignored. Finally,if a device is moved from one vehicle to another (e.g., because thedevice's user or only the device physically switches vehicles), the SyncSignal from the original vehicle can cease to be received in theexpected time slot or with the expected identity (for one or moretimes), whereupon it can be determined that the device is no longer inits original vehicle. It will then begin to receive the In-VehicleSignal from the new vehicle it has entered and begin the Sync Signal andDistance Signal processes in the new vehicle. Note that, in the examplepresented here there are no “crosstalk” issues related the DistanceSignal for similar reasons and/or they can be prevented in similar ways.Moreover, in certain implementations the probability of crosstalkbetween cars and devices can be further reduced, for example, by usingtwo (or more) successive Sync Signals (or Distance Signals) to computethe distance between the device and the transmitter where the length oftime between the Sync Signal (or Distance Signals) can be randomlyvaried on each transmitters and conveyed to their devices (e.g., thenext Sync Signal will occur t seconds after the this Sync signal, wheret is randomly drawn over some interval (0,X]).

It is noted that the detection and the time-stamping of the signalsreceived can be done with sufficiently low latency and sufficiently highresolution so that the in-vehicle location can be determined withsufficient accuracy. In one embodiment this is accomplished by movingthe detection and time-stamping processes to a location in the device'sstack architecture (hardware, firmware, operating system, application,etc.) that supports the requisite latency and clock resolution.

It is also noted that the set of rules used to determine the in-vehiclerole of the device user can be adjusted in different cases. For example,such rules can be adjusted based upon the geometry of a car (e.g.,larger cars have a higher distance threshold) or the location of thein-vehicle transmitter. Such information can, for example, be storedin-vehicle (or on a server external to the vehicle) and communicated bythe transmitter to the device (for example, as part of the Sync Signal)and used to adjust the in-vehicle role determination rules.

In another implementation, in order to save device power, even when adevice is determined/known to be in a moving vehicle, the device can beconfigured not to process the Sync Signal and/or the Distance Signaldescribed above (or the vehicle can be configured not to transmit suchsignals based on a determination that there no other powered-on devicesare present within the vehicle), until a certain device-based eventoccurs (e.g., the screen turns on, a phone call arrives, etc.),whereupon, before giving control to the user, the device can determineits in-vehicle location and determine/infer its user's in-vehicle roleand apply the usage rules, such as by using the methods described above.In certain implementations the Sync Signal can be configured to be sentmore frequently than once every 5 seconds, or the device might demand animmediate a Sync Signal from the vehicle (BT, WiFi, server-side) or thetransmitter (in which case it would be transceiver, able to receivecertain signals too).

In some implementations the vehicle and/or the device can be configuredsuch that one or more aspects of the functionality described herein is(a) be pre-installed or silently or conspicuously post-installed ondevices; and/or (b) run autonomously on devices, i.e., it willconstantly function without the user being able to turn it off,uninstall it or opt out, except, perhaps, by powering off a deviceand/or a vehicle. It can be appreciated that such configurations can,for example, be dictated or incentivized by regulation, legislation,policy or decision.

In other implementations, other methods (e.g., triangulation methods),involving more than one in-vehicle transmitters in different (or thesame) locations can be employed, thereby providing more robust (e.g.,less noise, more accurate in-vehicle location) than the example detailedabove, but would also likely cost more. It should be understood that thevarious illustrations provided herein are merely exemplary and that suchtechnologies can be modified to provide any number of additionalimplementations, as can be appreciated by one of ordinary skill in theart. Moreover, it can be appreciated that various devices have multiplemicrophones located in different known positions that can be used toreduce noise and improve accuracy and provide sound localizationinformation.

It should be understood that the in-vehicle transmitters do not have tobe integrated into the vehicle, e.g., they could be externally attachedor installed for after-market purposes.

It may be advantageous to enable notifications to be generated andprovided to certain persons if the transmitters cease to functionproperly, including being tampered with. This could be done device-sideor vehicle-side.

In certain implementations, the system described above could bereversed, e.g., the mobile device can be the transmitter and in-vehiclesensors can receive the signals (or a hybrid combination thereof, i.e.,some in-vehicle sensors receive while others transmit).

It should also be noted that the techniques described above can beimplemented with respect to the classroom techniques described herein,whereby the devices in a particular classroom can be identified usingthe techniques described above where the transmitter can be theteacher's mobile device (or a separate in-class transmitter) and thosemobile devices that receive the Distance Signal within a certainthreshold period of time are determined to be in the teacher's class andcan be controlled by signals sent from the teacher's phone as describedherein.

In another implementation, two or more transmitters that emit signals(e.g., BT, Win, ultrasound, inaudible-sound, light, etc.), such as thoseof the same type and/or with the same transmission power, can beincorporated within one or more hardware devices that can be installedwithin a vehicle. Such transmitters can be designed/configured totransmit spherically and/or directionally (e.g., in a three-dimensionalrange that is a subset of a sphere, e.g., a hemisphere, through the useof appropriate hardware as is known to those of ordinary skill in theart). Based upon the strength (or differences thereto) at which a devicecan be determined to receive the signals, one or more aspects pertainingto the in-vehicle position of a mobile device can be determined. Forexample, based on a determination that a mobile device is present in thefront left section of a vehicle, one or more restrictions can be placedon/in relation to the device. In another example, based on adetermination that a mobile device is present in the front right sectionof a vehicle, one or more restrictions (e.g., those that were placed onthe device when it was determined to be in a vehicle) can beremoved/relaxed from/in relation to the device. It should be understoodthat in locations where vehicles travel on the left side of the road(e.g., U.K.), such techniques can be reversed.

It can be appreciated that the strength of a signal emitted by a nearbytransmitter as perceived on a mobile device can vary from device todevice within the same location, orientation and time (e.g., because ofreceiver hardware, antenna placement, etc.), from device orientation todevice orientation and from device context to device context (e.g., in abag, in a pocket, in a cradle). Measuring the difference in strength ofa signal from two or more transmitters, transmitting with the sametransmission power, e.g., the difference in their RSSIs, and,optionally, averaged over time, can provide more accurate locationinformation.

In another implementation, the system can be reversed so that a mobiledevice emits one or more a signals that are received by one or morehardware devices and, based upon the relative strength (or differencesthereto) at which the hardware devices can be determined to receive suchsignals, one or more aspects pertaining to the in-vehicle position of amobile device can be determined.

In one implementation, transmitters can encode information about thedirection in which they transmit (e.g., right front, front right) withinthe transmission packets (e.g., SSID, payload) and the receiver (and/orother devices) can use such information, in addition to the signalstrengths, to determine the in-vehicle position/location of the device.

For example, a hardware device placed on the ceiling in the approximatemiddle of a vehicle might have three directional transmitters in it. Onetransmitter can emit signals pointed downward at the front left of thevehicle (e.g., ⅛ of a sphere). A second transmitter can emit signalspointed downward at the front right of the vehicle (e.g., ⅛ of asphere). A third transmitter can emit signals pointed downward at therear of the vehicle (e.g. ¼ of a sphere). The SSIDs of the transmittercan contain the suffix strings “FL”, “FR”, and “Rear”, respectively (SeeFIG. 51). Accordingly, in a scenario in which a mobile device within thevehicle determines that the strongest signal that it receives (over oneor more samples) has “FL” in its SSID suffix, it can be determined thatthe device is likely to be in the front left of the vehicle. Moreover,by averaging the strengths of successive signals closely spaced in time,the accuracy of such a technique can be further improved. The accuracycan be further improved by requiring that the difference between thestrength of two or more signals exceed one or more thresholds prior todetermining its location. For example, a device near the front of thevehicle (the device might be determined to be in the front because the“FL” and “FR” signals acquired are much stronger than the “Rear”signal), might only be determined to be in the front right of thevehicle if the difference in the strength between the FL signal and theFR signal (e.g., RSSI_(FL,t)-RSSI_(FR,t)) was (a) greater than 0 on morethan 90% of 10 samples, each 500 ms apart; or (b) greater than 3 dbms,on average, over 10 seconds; or (c) had a mean that was more than onestandard deviation above zero, over 7 seconds.

In another implementation, the hardware unit described above can bemodified so that the “FL” ⅛-sphere is enlarged slightly while the “FR”⅛-sphere is minimized slightly and as soon as the FR signal isdetermined to be stronger than the FL signal (i.e., without the need forany additional margins of error), the device can be determined to be apassenger device (see FIG. 52)

In another implementation, the two or more transmitters can be placed intwo different units, for example, two in the front window (“FL”, “FR”)and one in the rear window (“Rear”). Such placement may be preferable incertain implementations because it can utilize solar energy to power thetransmitter(s).

In various implementations the physical structure of the hardware unit(e.g., relative to the wavelength of signal) can be designed orconfigured to prevent/minimize the RF signals from spreading outside thepolygonal/conal direction in which they are directed/intended to betransmitted after they leave the hardware unit, as is known to those ofordinary skill in the art.

In various implementations, the transmission units may be installed asoriginal equipment (OE) by the vehicle manufacturers or theirsubcontractors, or in after-market by specialists or via ‘do ityourself’ kits.

In certain implementations, crosstalk can be minimized by using uniqueidentifiers (e.g., BSSID) for all the transmitters within the samevehicle (in addition to the directional information) and ignoring allsignals but those that are determined to be the strongest (collectivelyacross all the transmitters in a vehicle). Continuing the three (3)transmitter example above, the BSSIDs of the transmitters in the samedevice are 123456000001, 123456000002, and 123456000003. When a devicein the vehicle receives vehicle-location signals with a prefix 123456and 654321, with strength of −20 dBm, −30 dBm, −40 dBm, −40 dBm, −50dBm, −60 dBm for 123456FL, 123456FR, 123456Rear, 654321 FL, 654321 FL,654321 FL, it can compute the average signal strength from devices withthe prefix 123456 and prefix 654321, i.e., −30 dBm and −50 dBM,respectively, and can choose to ignore the signals from the“crosstalking” signals, i.e., the signals with the 654321 prefix.

It should be noted that, in certain implementations, a device can berestricted in a manner that reduces the danger likely to result fromnoises emitted by device (e.g., when present within a vehicle), such asnoises that may negatively affect a driver's abilities to perform hisprimary task. Upon determining, for example, that a device is presentwithin a moving vehicle, applications that use sounds which, if playedwhile in a vehicle may be confusing, distracting, dangerous, etc. (e.g.,a honking sound, a siren, loud sounds), can be adjusted (e.g., byselecting different/less confusing sounds, using another feedbacktechnique, e.g., haptic feedback, or by restricting the soundsentirely). In certain implementations, such applications can ask (e.g.poll) a trip detection module (e.g., on the mobile device) or receive anotification (e.g., subscribe to a callback) from a trip detectionmodule when a trip starts and stops.

Turning now to FIG. 12, a flow diagram is described showing a routine1200 that illustrates a broad aspect of a method for restrictingoperation of a mobile device 105 in accordance with at least oneembodiment disclosed herein. As will be described in greater detailbelow, various of the steps and operations that make up routine 1200share substantial similarities to those described in detail herein.

At step 1201, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 determines whether afirst mobile device 105 is present within a vehicle, and/or receives oneor more first inputs from at least one of a vehicle data system 164and/or at least one of a second mobile device 160, the one or more firstinputs pertaining to a presence of the first mobile device 105 within avehicle, such as through one or more of the various determinationmethods described in detail herein.

Then, at step 1207, mobile device 105 preferably prompts one or moreusers to initiate and/or provide one or more stimuli that can bereceived as inputs at mobile device 105 and/or receives one or moresecond inputs in response to the prompting, and/or receives one or morethird inputs from vehicle data system 164, and/or receives one or morefourth inputs from at least one of the second mobile device 160, all inthe manner described in detail herein.

At step 1220, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, analyzes at leastone of the first inputs, the second inputs, the third inputs, and thefourth inputs to determine a presence of at least one of more than oneuser, more than one mobile device 105, 160, and/or one or more users notin the set of users known to be users of the first mobile device,substantially in the manner described in detail herein.

At step 1242, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 employs one or morerestrictions at a mobile device 105, substantially in the mannerdescribed in detail herein.

Turning now to FIG. 13, a flow diagram is described showing a routine1300 that illustrates a broad aspect of a method for restrictingoperation of a mobile device 105 in accordance with at least oneembodiment disclosed herein. As will be described in greater detailbelow, various of the steps and operations that make up routine 1300share substantial similarities to those described in detail herein.

At step 1305, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs one or morerestrictions at mobile device 105, substantially in the manner describedabove with respect to step 705.

In certain implementations, such a restriction can be employed wherebythe device can prompt/require the user is to authenticate that s/he is apassenger in a vehicle (such as a moving vehicle) by performing anaction or a set of actions such as a CAPTCHA, a game, a puzzle, lockscreen etc., as described in detail herein. It can be appreciated thatsuch authentication can be configured to require sufficientconcentration/attention such that the authentication can be difficult toperform by a driver of a moving vehicle, who must concentrate ondriving. This authentication can be further strengthened by requiringthat (a) in order to complete the action the user must use both hands(for example, by requiring multitouch input, as described in detailherein and illustrated with respect to FIG. 15A), and/or (b) configuringthe restriction to require the user to tilt his/her head and/or eyesdown or up or right or left (for example, by requiring that the devicebe held flat, placed in the user's lap or on the seat between the user'slegs, in the manners described herein) thereby preventing the user frombeing able to see the road ahead while performing the authentication,and/or by requiring that the user look directly in to the device, asdescribed in detail herein.

At step 1310, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or moreinputs, preferably from at least one of the mobile device 105, a vehicledata system 164, and/or one or more other mobile devices 160,substantially in the manner described above with respect to step 710. Byway of further illustration, in certain implementations, such inputscorrespond to one or more inputs provided by the user to the device inresponse to an authentication prompt (it should be understood that theterm “authentication prompt” as used herein is intended to encompass oneor more prompts, instructions, and/or directions that inform a user insome manner as to the manner in which inputs should be provided to adevice, and/or that otherwise provide information to the user relatingto the authentication of such a device).

At step 1320, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, analyzes at leastone of the inputs. It should be understood that in certainimplementations, such analysis can be performed in order to determine apresence of one or more users that are not known users of the firstmobile device 105, substantially in the manner described in detailherein. In other implementations, such analysis can be performed inorder to determine whether and/or to what degree one or more inputs(such as those received at step 1310) successfully and/or unsuccessfullyauthenticated a mobile device 105, as is also described in detailherein.

At step 1342, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, modifies anemployment of one or more restrictions at a mobile device 105,substantially in the manner described in detail herein.

Turning now to FIG. 14, a flow diagram is described showing a routine1400 that illustrates a broad aspect of a method for orienting acoordinate system of a mobile device 105 in accordance with at least oneembodiment disclosed herein. As will be described in greater detailbelow, various of the steps and operations that make up routine 1400 canshare substantial similarities to those described in detail herein. Itshould be understood that the various steps of routine 1400 will beappreciated with reference to EXAMPLE 3 below and FIGS. 9-11B, and theiraccompanying descriptions.

At step 1410, processor 110 executing one or more of software modules130, including, preferably, determination module 170 receives one ormore inputs, preferably from at least one of (i) at least one of theuser interface, the operating system, the accelerometer, the gyroscope,the GPS receiver, the microphone, the magnetometer, the camera, thelight sensor, the temperature sensor, the altitude sensor, the pressuresensor, the proximity sensor, the NFC device, the compass, and thecommunications interface of the mobile device 105 and (ii) a vehicledata system 164, substantially in the manner described in detail herein.

At step 1430, processor 110 executing one or more of software modules130, including, preferably, determination module 170 computes, based onthe one or more inputs, an orientation of the mobile device 105 relativeto a coordinate system of a vehicle, such as a vehicle within whichmobile device 105 is traveling.

At step 1440 based on the orientation, processor 110 executing one ormore of software modules 130, including, preferably, determinationmodule 170 interprets one or more subsequent inputs of the mobile device105 in relation to the coordinate system of the vehicle and/ortransforms the one or more subsequent inputs originating at the firstdevice into values that are comparable with the coordinate system of thevehicle. See, for example, FIGS. 11A-B and EXAMPLE 3, below.

It should be understood that mobile device 105 is preferablycommunicatively coordinated with the vehicle data system, that vehicledata system is preferably configured (e.g., installed) with the vehicle(e.g., within the vehicle such as a car) and/or that mobile device ispositioned within the vehicle, as described in detail herein.

By way of illustration, consider that based on the x, y and zaccelerometers, the exact orientation of the device 105 can bedetermined relative to the ground (e.g, based on the gravitational forceshown on the three accelerometers 145A, as is known to those of skill inthe art based on such disciplines as trigonometry). When the device iswithin a moving car with additional forces, the inputs can be averagedover time and/or inputs from the gyroscope 145B can further assist thiscomputation.

The orientation of the mobile device 105 can be detected relative to thecar, for example, by using the angle between the device's magnetic north(e.g, from the 3-axis compass sensor) and the vehicle's GPS heading (ascan be shown on the mobile device).

Accordingly, it can be appreciated that in the case of a moving carthere are also additional forces (other than gravity). These forces canbe accounted for, for example, through averaging over time and/or byusing the mobile device's gyroscope 145B, as described herein and usingmethods known to those of ordinary skill in the art.

In the case that there are movements at the mobile device 105 that areunrelated to the car (say the user moved the device), these can beaccounted for through time averaging and/or using the gyroscope 145B andor filtering out these higher frequency events, as described herein andusing methods known to those of ordinary skill in the art.

By way of further illustration, consider that in a mobile device on aflat table, the Z-accelerometer shows gravity and the X-accelerometerand Y-accelerometer show 0.

If the mobile device is rolled or pitched (so that one side or onecorner of the device remains in contact with the table), the value readby the z-accelerometer goes down (some of the gravity that it felt instage one is handed over to the other accelerometers) and theX-accelerometer (for roll) and Y-accelerometer (for pitch) go up. Thetotal sum of squares of the 3-accelerometers is always gravity. So weknow the exact orientation of the device with regard to the ground.

To orient/align the device 105 with the coordinates of a car, thedevice's 105 north (detected, e.g., via its compass sensor) can becompared with the vehicle's GPS (such as from vehicle data system 164)heading (as read on the device). For example, (if the device screen isfacing up, i.e., the device is not upside down) and its compass sensorshows that magnetic north is due north and the GPS heading sensor showsthe vehicle is travelling due west, then the device is rotated 90degrees to the right with regard to the car. Accordingly, the exactorientation of the device with respect to the coordinates of the car, asdisclosed herein and described in greater detail at EXAMPLE 3 and withregard to FIGS. 9-11B.

By way of further illustration, in the case of a 2.5 g lateralacceleration detected at the mobile device 105, that could be becausethe mobile device 105 was in a very tight turn (right or left) orbecause there was very strong forward acceleration or deceleration—orsome combination thereof. We cannot know what the car did (if anything)to cause this 2.5 g acceleration until we understand the orientation ofthe device 105 within the car and can transform the 2.5 g lateralacceleration felt on the phone into the acceleration in the vehicle'scoordinate system, which is achieved through implementation of routine1400.

It should be noted that, for the purpose of the simplicity of thedescription and without any loss of generality, in one or more of theexamples below, it will be assumed that the various mobile device(s)105, 160 is (are) aligned with the vehicle within which they aretraveling, such as shown in FIG. 11A. That is, the coordinate system ofa particular mobile device 105, 160 should be understood to becoincident with the vehicle's coordinate system, as depicted in FIG. 11Aand described in greater detail in EXAMPLE 3. It should be furtherrecognized that in practice, such as in various arrangements, such asthat shown in FIG. 11B, mobile device 105, 160 is rotated with respectto the coordinate system of the vehicle in up to three dimensions. Inorder to correctly analyze the various inputs originating at sensors 145of mobile device 145 within the context of the coordinate system of thevehicle, the rotation of the particular mobile device 105, 160 relativeto the vehicle is preferably computed and the inputs originating atsensors 145 of the particular mobile device 105, 160 are preferablytransformed into values for the coordinate system of the vehicle. Thismay be achieved in various ways, examples of which are provided below.

It should also be noted the several of the examples provided herein arepresented from an event-centric perspective for the purpose of clarity.That is, various of the inputs originating at sensors 145 of mobiledevice 105, 160 have been described as corresponding to variousreal-world events such as turns, bumps, and/or stops. Accordingly, itshould be appreciated that such event-centric descriptions are providedherein for the purposes of illustration and clarity, and are notintended in any way to be understood as limiting the scope of thepresent disclosure. Additionally, is should be appreciated that thevarious determinations described herein can also be performed from asensor-centric perspective, wherein the various inputs originating atsensors 145 are considered, irrespective of a particular real-worldevent to which they correspond. It should be understood that the variousapproaches described herein can be employed in both even-centric andsensor-centric perspectives.

It should be understood that the following examples encompass furtherarrangements and embodiments of the systems and methods disclosedherein.

Example 1

There are a number of inputs that can be utilized in variousarrangements in order to identify one or more user determinationcharacteristics, such as the location of a mobile device 105 and/or if amobile device 105 is being operated by the driver or by the passenger ofa car/truck/bus, such as:

As also noted above, various arrangements preferably incorporateidentification of one or more of the user determination characteristicsreferenced above and herein. In certain arrangements, each userdetermination characteristic (e.g. error proportion, correlation oftyping speed to acceleration etc.) can be considered as a point in aK-dimensional space. Classification algorithms based on supervisedlearning, as are well known to those of ordinary skill in the art, canthen be applied to the resulting K-dimensional signature(s) to determinethe probability that the in-vehicle role of the user of mobile device105 is a driver or a passenger.

Text Reading/Screen Viewing—User determination characteristic(s) can beidentified based on patterns in the reading of text messages (or anyother such text item such as an email or webpage, or any other suchviewing of items on a display screen, such as during the playing of avideo game) on a mobile device 105, thereby serving to distinguishbetween a driver and a passenger. For example, drivers tend to changethe orientation of and/or move (e.g. rotate in his/her palm) mobiledevice 105 more frequently when attempting to read a message of a givenlength (in order to periodically glance back at the road), whereas apassenger will read such a message in a comparatively more constantstate. This is especially true during road maneuvers that require moredriver concentration, such as turns and accelerations. This phenomenoncan be observed as a high degree of correlation between vehicleaccelerations and/or gyroscopic rotations as detected by accelerometer145A and gyroscope 145B, respectively, of mobile device 105 and thechanges in orientation of the mobile device 160 (unrelated to movementsin the vehicle) as measured by one or more of accelerometer 145A,gyroscope 145B, GPS 145C and magnetometer 145E and, in particular, thepresence or absence of a (non-vehicle related) mobile device movementsjust prior to vehicle movements. Preferably, once this correlationreaches or exceeds a certain threshold, the in-vehicle role of the userof mobile device 105 can be determined to be a driver and/or once thiscorrelation reaches or exceeds another certain threshold, the in-vehiclerole of the user of mobile device 105 can be determined to be apassenger.

Driver-Specific Movements—Various movements and/or forces can bedetected by one or more of sensors 145 of mobile device 105 that can bedetermined to be unique to a driver. In the alternative, a lack ofperception of such unique forces, such as “signature” forces at a mobiledevice 105 can indicate that the user of such a device is not a driverand is thus a passenger. When in contact with a device 105 (such as whenholding it), a driver influences the movement of a mobile device 105through driver-related actions that include pressing and releasing thegas/brake/clutch pedals and by moving his/her foot from one pedal toanother over the course of driving. For example, prior to a period ofstrong and prolonged acceleration perceived by accelerometer 145A ofmobile device 105 (which is typically due to acceleration, braking,and/or wheel rotation), there is a smaller, different accelerationand/or angular movement perceived slightly (in the 100's ofmilliseconds) in advance, such as at one or more of sensors 145, thatoriginates at the driver's body maneuver (such as the pressing of a gaspedal) that initiates the acceleration of the vehicle. A driver alsocauses a mobile device 105 to move by rotating the steering wheel. Thus,in a case where a mobile device 105 is in contact with a driver turninga steering wheel, various of sensors 145, such as accelerometers 145Aand/or gyroscope 145B of mobile device 105 can detect certainaccelerations and rotations. Based on a retrospective analysis of suchinputs—for instance, analyzing inputs corresponding to acceleration of acar with inputs perceived immediately prior—it can be determined whetherthe user operating such a mobile device 105 is a driver or a passenger.If such unique/signature forces are perceived in close proximity(generally, immediately before) acceleration, etc., it can be determinedthat the user is a driver. Conversely, if such inputs are not detectedimmediately prior to acceleration, it can be determined that the user isa passenger (provided that the user is in physical contact orcommunication with mobile device 105).

By way of further illustration, prior to a period of strong andprolonged lateral acceleration and/or gyroscopic yaw perceived byaccelerometer 145A and gyroscope 145B of mobile device 105 due toturning, there is a smaller, different acceleration and/or angularmovement perceived slightly (in the 100's of milliseconds) in advancethat originates at the driver's body maneuver that initiates the turningof the steering wheel and that is unlikely to be that of a passenger.

This approach can be also applied to other driver movements (e.g.,looking in the mirrors, turning on the directional signal), wherein thedriver's movements will be detected on mobile device 105 that is incontact with the driver slightly before another signal is detected(e.g., accelerometer 145A or gyroscope 145B for looking in mirrors,microphone 145D for turning on directional), on mobile device 105,whereas these serial relationships will not be present if mobile device105 is being operated by a passenger.

In certain implementations, a device determined to be located within avehicle can process various inputs, such as in order tocharacterize/determine the nature of a particular movement of thevehicle. For example, various inputs can be processed in order todifferentiate between a vehicle that has recently stopped moving and islikely to continue its present trip (e.g., stopped at a red light orstopped in traffic) from a vehicle that has recently stopped moving andis relatively likely to have finished its present trip. In doing so, itcan be determined when usage/operational restrictions (such as thosedescribed herein) employed with respect to a device determined to beoperated by a driver of a vehicle should be lifted or otherwisemodified/eased (e.g., upon determining that the vehicle is relativelylikely to have finished its present trip, as opposed to only coming to atemporary stop), such as in the manner described herein.

FIG. 35 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3505 one or more inputs can bereceived, such as in relation to a user device. At 3510, at least one ofthe one or more inputs can be processed. In certain implementations, atleast one of the one or more inputs can be processed in order todetermine one or more mobility characteristics of the device. Moreover,in certain implementations one of the one or more inputs can beprocessed based on a determination of a mobility stoppage, such as inrelation to the user device. In certain implementations, one or moreinputs that are chronologically proximate to the mobility stoppage canbe processed, such as in order to determine one or more mobilitycharacteristics of the device. Moreover, in certain implementations theone or more mobility characteristics can include at least one of (a) apermanent stop or (b) a temporary stop. Moreover, in certainimplementations, at least one of the one or more inputs can be processedin relation to one or more data items, such as in order to determine oneor more mobility characteristics of the device. In certainimplementations, the one or more data items can include at least one of:map data, traffic signal data, or traffic condition data. At 3515, oneor more restrictions can be selectively adjusted, such as in relation tothe user device. In certain implementations, one or more restrictionscan be selectively adjusted based on the one or more mobilitycharacteristics.

FIG. 36 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3605 an indication of a completion of atrip can be received, such as in relation to a user device. At 3610, oneor more inputs can be processed, such as in order to determine one ormore mobility characteristics of the user device. In certainimplementations, such one or more inputs can be processed based on theindication. At 3615, the one or more mobility characteristics can beprocessed, such as in order to determine a veracity of the indication.In certain implementations, the one or more mobility characteristics canbe processed in relation to the indication. At 3620, one or morerestrictions can be selectively adjusted, such as in relation to theuser device. In certain implementations, one or more restrictions can beselectively adjusted based on the veracity. In certain implementations,one or more restrictions can be maintained, irrespective of a subsequentindication of a completion of a trip.

In one implementation, one or more inputs that correspond to thebehavior or operation of a vehicle prior to its stop, such as thoseoriginating at the accelerometer, GPS, magnetometer, and/or gyroscope ofthe device can be processed, for example, in order to determine whetherthe vehicle traveled in reverse one or more times just before it stopped(indicating parallel parking), and/or whether the vehicle performed aturn in the period of time just preceding its stop (indicating entryinto a parking lot or a driveway).

In another implementation, the frequency and/or length of stops (asdetermined based on a processing of one or more of the inputs referencedherein) made in the time prior to the current stop can be used todifferentiate between these two states (i.e., between a temporary and apermanent stop). A vehicle determined to have made stops (of variouslengths) in the recent past and/or in close proximity to the location ofthe current stop and/or is on a travel route determined to be consistentwith the previous stops, can be determined to be relatively more likelyto be stuck in traffic than a vehicle that has not.

In another implementation one or more inputs originating at a device'slocation sensitive sensor/radio (e.g., the GPS of the device) can beprocessed to determine (a) whether the vehicle is near a traffic light,(b) whether the acceleration/deceleration of the vehicle (i.e., stoppingand going) correlates with the changes in the traffic lights (e.g.,their green-yellow-red pattern) on the route that the vehicle isdetermined to be traveling, and/or (c) whether the vehicle is on a roadthat currently has heavy traffic that could be the cause of the stopsobserved, as can be aided by data originating at one or more trafficdensity services (e.g., Waze, DeCell, etc.).

FIG. 53 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 5310, one or more inputs can be received. In certain implementations,such inputs can be received in relation to a geographic location (e.g.,one or more coordinates, a location on a map, an address, etc.).Moreover, in certain implementations the referenced inputs cancorrespond to an incidence of deceleration (e.g., slowing down,stopping, etc., such as of a vehicle).

In certain implementations, the referenced geographic location caninclude, incorporate, and/or otherwise be associated with information,parameters, metadata, etc., such as may reflect or otherwise pertain toa presence of a stop sign, traffic light, a parking lot, parking spot, anon-temporary location such as an office or home, etc. (and/or any othersuch status or indication that may reflect a likelihood that a vehiclestopping there may be likely to maintain such a stop for a relativelyshort time, such as at a stop sign or traffic light, or a relativelylonger time, such as at a parking spot or parking lot) at the geographiclocation. As described herein, the presence of such items at/in relationto the location can be used/accounted for in determining whether theincidence of deceleration (e.g., the stopping of a vehicle) is likely tobe maintained for a relatively shorter time duration (e.g., in the caseof a vehicle stopping at a stop sign) or a relatively longer timeduration (e.g., in the case of a vehicle stopping in a parking lot orparking spot).

Moreover, in certain implementations the referenced geographic locationcan include information pertaining to one or more previous incidences ofdeceleration at the geographic location. That is, as described herein, ahistory or log of previous deceleration/stopping instances can beutilized/accounted for in determining whether a deceleration instance(e.g., the stopping of a vehicle) in a particular location is likely tobe for a relatively shorter time duration (e.g., temporary) or for arelatively longer time duration. Thus, a location with respect to whichit can be observed or determined that several or many of the previousdeceleration instances were for a relatively shorter time duration canbe identified/classified as a short term stop location, while a locationwith respect to which it can be observed or determined that several ormany of the previous deceleration instances were for a relatively longertime duration can be identified/classified as a longer term stoplocation. Additionally, in certain implementations, such previousincidences of deceleration (e.g., at the geographic location) caninclude one or more previous incidences of deceleration at thegeographic location that are associated with a user that is associatedwith a device (e.g., the device with respect to which a restriction isto be modified, such as at 5330). That is, a user or driver's personalhistory or log can be accounted for in determining whether a location isa short or long term stopping location. For example, with respect to alocation that may otherwise be determined to be a short term stoppinglocation (e.g., near a stop sign), in a scenario in which multiple longterm stopping instances can be observed/identified at such a locationwith respect to a particular user (e.g., on account of the fact that theuser's driveway is nearby), such a location can be determined to be along term stopping location with respect to that user.

In certain implementations, the referenced inputs can be received inrelation to an approach towards the geographic location (e.g., asdescribed herein, when the referenced deceleration occurs in relation toan approach towards the location, as opposed to a departure from thelocation). In such a scenario, the referenced geographic location can bedetermined to be a relatively shorter term stopping location. In such ascenario (as well as in other scenarios, such as are described herein),based on a determination that the incidence of deceleration isrelatively likely to be maintained for a relatively shorter timeduration (corresponding to a temporary stop, such as at a stop sign), animplementation of a restriction can be maintained at the device, such asis described herein.

In certain implementations, the referenced inputs can be receivedsubsequent to a departure from the geographic location (e.g., anincidence of deceleration/stopping after a vehicle passes a stop sign ortraffic light). As described herein, in such a scenario, the referencedgeographic location can be determined to be a relatively longer termstopping location. Moreover, in such a scenario, an implementation of arestriction at the referenced device can be modified upon such adetermination (e.g., a determination that the incidence of decelerationoccurred subsequent to the departure from the geographic location).

In certain implementations, information pertaining to one or moreprevious incidences of deceleration at a geographic location that areassociated with a user that is associated with a device (e.g., ashort/longer term stop history associated with a user) can be receivedor otherwise identified or accounted for based on a relative prevalenceof other locations within a defined proximity to the geographic locationthat are determined to be relatively shorter term stopping locations.For example, as described herein, upon determining that there areseveral other short term stopping locations within a certain distance ofa particular location, a stopping history associated with a user can beutilized/accounted for to determine if the particular location is (or isnot) likely to be a short term stopping location (e.g., with respect tothe user).

At 5320, the one or more inputs (such as those received at 5310) can beprocessed. In certain implementations, such inputs can be processed inrelation to a geographic location (such as a geographic location inrelation to which they were received). In doing so, a relativelikelihood that the incidence of deceleration is to be maintained for arelatively shorter time duration and/or a relatively longer timeduration can be determined.

Moreover, in certain implementations the referenced inputs (such asthose received at 5310) can be processed in relation to one or moresignals that are perceptible to a device (e.g., wireless signals such asWin, Bluetooth, etc.). In doing so, determine a relative likelihood thatthe incidence of deceleration is to be maintained for a relativelyshorter time duration and/or a relatively longer time duration can bedetermined, such as is described herein.

In certain implementations, the referenced inputs can be processed inrelation to a geographic location (such as the location with respect towhich the inputs were received) and/or a relative prevalence of otherlocations within a defined proximity to the geographic location that aredetermined to be relatively shorter term stopping locations. In doingso, a relative likelihood that the incidence of deceleration isrelatively likely to be maintained for a relatively shorter (or longer)time duration can be determined.

In certain implementations, the referenced inputs can be processed inrelation to a geographic location and/or one or more chronologicalcharacteristics (e.g., a time of day, a day of week, or a day of month,reflecting, for example, that a particular location may be a temporarystopping location at a certain time/date—e.g., during rush hour onweekdays—but not at other times/dates). In doing so, a relativelikelihood that the incidence of deceleration is relatively likely to bemaintained for a relatively shorter (or longer) time duration can bedetermined, such as is described herein.

In certain implementations, the referenced inputs can be processed inrelation to one or more factors, characteristics, aspects, etc.,including but not limited to: the geographic location, weatherconditions, traffic conditions, date/time conditions, etc. (as describedherein, a particular location may be a temporary stopping location whensuch factors are present, but a longer term stopping location when theyare absent). In doing so, a relative likelihood that the incidence ofdeceleration is relatively likely to be maintained for a relativelyshorter (or longer) time duration can be determined.

At 5330, an implementation or application of one or more restriction(s)can be modified. In certain implementations, such restriction(s) may beemployed at, on, and/or in relation to a device (e.g., a smartphone orany other such device). Moreover, in certain implementations animplementation or application of such restriction(s) can be modifiedbased on a determination (such as at 5320) that the incidence ofdeceleration is relatively likely to be maintained for a relativelylonger time duration.

In certain implementations, a threshold can be adjusted. Such athreshold may define a chronological interval upon expiration of whichthe implementation of the restriction can be modified (e.g., eased orremoved/disabled), such as is described herein.

In certain implementations, a notification can be provided (e.g., at/inrelation to the referenced device). Such a notification can, forexample, reflect a time duration (e.g., a countdown timer) uponexpiration of which an implementation of the referenced restriction isto be modified. In certain implementations, such a time duration can bedefined based on a relative likelihood that the incidence ofdeceleration is to be maintained for a relatively shorter time duration(in which case a relatively shorter time duration can be utilized and/ora relatively longer time duration (in which case a relatively longertime duration can be utilized).

In certain implementations, a selectable control can be provided, e.g.,at an interface of the device. When selected, such a control caninitiate a modification of the implementation of the restriction, suchas is described herein. In certain implementations, as described herein,such a control can be provided based on a determination that thereferenced incidence of deceleration is relatively likely to bemaintained for a relatively longer time duration as well a determinationthat the device is not moving faster than a defined speed threshold,and/or a determination that the perceptibility of one or more accesspoints (e.g., WiFi access points, etc.) does not change over a definedchronological interval, such as is described herein.

By way of further illustration, it can be advantageous to differentiatebetween incidences of relatively short or shorter term/temporarydeceleration/stopping (e.g., stops that are likely to last for arelatively short period of time) from those that are more likely tocontinue be for a relatively longer length of time (as noted, thelocation where a trip has stopped as well as whether it has stopped canbe determined using one or more mobile device sensors, including, butnot limited to, GPS, cellular radio, WiFi radio, Bluetooth,accelerometers, gyroscopes, etc. as are known to those of ordinary skillin the art and a trip that is likely to end soon can be determined usingone or more of such sensors, as well as historical information about thelocational behavior of the device in question and/or other devices). Indoing so, for example, one or more applications (such as those operatingon and/or in relation to a device) can determine whether or not tocontinue implementing one or more restrictions (e.g., in relation to adevice determined to be operated by a driver), such as during atemporary/short stop, or whether to remove one or more restrictionsand/or to return full device access/operation (e.g., in relation to adevice determined to be operated by a driver), such as during arelatively longer stop.

In one implementation, a determination as to which stops are more likelyto be temporary/short and which are more likely to be longer can beachieved by associating various determinations of acceleration,deceleration, and/or stopping/starting a trip (and during the intervalsbetween them) (e.g., using clustering, grouping, characterizing,classifying (e.g, kNN) etc., techniques, as are known to those ofordinary skill in the art) with the respective characteristics of thelocation (e.g., geographic location, one or more devices, e.g.,RF/wireless devices, and/or signals that are present/perceptible in alocation) in which they occur (e.g., as determined using one or more ofGPS, WiFi, cellular, BT on a mobile device and/or the vehicle in whichthe device is traveling). It should be understood that suchdeterminations can be made by using data acquired from a single deviceand/or multiple devices (e.g., via ‘crowdsourcing’). In doing so, thelocations of landmarks such as traffic lights, stop signs (e.g., if asufficiently high time frequency sampling is used to identify stops ofsuch length) and additional locations that may be less apparent/obvious(e.g., those that pertain to traffic patterns that cause temporary stopsat locations other than traffic lights and stop signs), all of which cancause various types of ‘stops’ during a trip, can be identified.

In one implementation in a scenario in which the referenced input(s)(e.g., from one or more sensors on a device) can be determined toindicate that there is an increased probability that that the device hasstopped moving (or, in some implementations even without such anindication(s)), various characteristics of previous stops (e.g.,quantity, frequency, mean length, median length, variability and othermoments of such lengths, cumulative length, days with stops, etc.)associated with the device (and/or other devices), in a scenario inwhich it determined that it was within, for example, a 100 m radius ofthe current location, can be utilized or otherwise accounted for indetermining whether the location is a temporary stopping location(‘TSL’), a long-term stopping location (‘LSL’) or neither (or, both).Alternatively and/or in addition, in lieu of associating thegeo-locations of the device with TSLs and/or LSLs, the identity ofvarious transmitters (e.g. cell towers, WiFi access points, Bluetoothdevices, etc.) can be associated with TSLs and LSLs (e.g., if the last25 times a device perceived a WiFi AP having a MAC address of12:34:56:78:9A:BC, the device was also determined to have stopped for 1hour, upon subsequently perceiving this address, it can be determinedthat it is at an LSL).

In another implementation, in addition to (or instead of) the varioustechniques described herein, determining whether a particular stop islikely to be temporary/short or longer can be achieved by associatingvarious incidences/determinations of stopping/starting during a trip(and the intervals between them) (e.g., using clustering, grouping,characterizing, etc., techniques, as are known to those of ordinaryskill in the art) with the respective signals (e.g., wireless signals,such as WiFi, Bluetooth, etc.) that are perceptible to the device whenthey occur. It should be understood that such determinations can be madewith respect to a single device and/or multiple devices(‘crowdsourcing’). When one or more wireless signals that has beenassociated with stopping/starting is observed, a determination may bemade as to the likely length of the stop (e.g., short or long). Forexample, if 14 of the last 15 times that (i) an input from one or moresensors (such as those incorporated within the device) indicated thatthe time for which the likelihood that the device was stopped wassufficiently high (e.g., greater than a certain threshold value); and(ii) the device was in the presence of or could otherwise perceive aWiFi signal with BSSID 11:22:33:44:55:66 with a signal strength greaterthan −80 dbm, and the device now perceives/is in the proximity of thisBSSID address again (and its signal strength is sufficiently high), thedevice can be determined to be stopped.

In another implementation, a determination can be made without evenconsidering inputs from the referenced sensors so that, for example, ifthe 14 of the last 15 times that the device was in the presence of BSSID11:22:33:44:55:66 with a signal strength greater than −80 dbm it wasstopped and the device is now in the proximity of this BSSID again (andits signal strength is sufficiently high), it can be determined to bestopped.

Upon determining that a device is at a temporary stopping location(“TSL”), it can be further determined/assumed that the device is stillwithin a trip (even though it is not currently moving), such as for alonger period of time than if the device were not at a TSL. Accordingly,upon determining that the device is present in/at a TSL, a relativelyhigher stopping threshold can be implemented before such a stop can bedetermined to be a long (i.e., non-temporary) stop. It can beappreciated that such a configuration can enable an application toaccount for stops determined to be at TSLs differently than stopsdetermined to have occurred at other locations, thereby reducing theincidence of incorrect, premature trip end determinations in scenarioswhere the device is stopped at a TSL and/or reducing the latency atwhich trip end determinations are made at locations that are not TSL.For example, a restriction implemented in relation to a device while thedevice is being operated by a driver and/or is present in a trip, can beremoved/modified relatively more quickly at the non-temporary end of atrip (thereby improving the accuracy and overall user experience ofapplications that account for such stops), while also preventingunauthorized/unsafe operation of the device in scenarios where a devicehas only stopped temporarily.

Alternatively, or in addition, stopping locations in which devices tendto stop for longer periods of time can be determined by virtue of thefact that moving devices that reach this location tend to stay there formore than a certain amount of time, e.g., a parking lot, a driveway.When a device is at such a long stopping location (‘LSL’), it can bedetermined to have finished a trip relatively faster (e.g., requiring arelatively shorter time threshold to have passed during which travelingis not perceived/determined) than would otherwise be assumed, such as inanother location (e.g., a location not determined to be an LSL). Indoing so, stops occurring in locations determined to be LSLs can beaccounted for differently than stops occurring at other locations and,thereby enabling determinations of trip ends with lower latency andreducing the likelihood of a false trip end determination, such as whenthe device is stopped at a TSL. For example, restrictions implemented ata device while driving/in a trip can be removed/modified relatively morequickly upon determining that the device has stopped at an LSL (incontrast to other locations with respect to which a relatively higherthreshold, such as a time threshold, may be required beforeremoving/modifying comparable restrictions).

In certain implementations, TSL/LSL information that is specific to aparticular device can be accounted for in conjunction with TSL/LSLinformation generated/associated with a larger population of devices.For example, if a particular intersection is identified as a TSL and auser happens to park in a parking lot that is located very close to suchintersection, the user would be deemed to be at a TSL even though his(personal) stop was longer than temporary. This might cause, forexample, a less positive user experience because, based on the devicebeing stopped at a TSL, the device may be configured to take relativelylonger to lift selective restrictions from the device (in light of beingpresent in a TSL, as described herein). But, if theparking-lot-near-intersection location was one in which the devicefrequented regularly (e.g., it was the parking lot for his company thatbe visited most weekdays), such a location can be identified as an LSLfor that user, while still being identified as a TSL for the generalpopulation, and the restrictions can be lifted/modified relatively morequickly, thereby improving the experience for that user.

In certain implementations, various configurations of the technologiesdescribed herein can be implemented based upon the TSL-density, thepopulation density and/or some other density metric, of the location thedevice is in. For example, in a dense urban location, e.g., New YorkCity, where there is a very dense packing of TSLs (e.g., many trafficlights), a system using TSLs/LSLs can be configured to place relativelyless weight on information derived from a population of devices andplace more weight on the information of a particular device than itotherwise would (e.g., in other locations).

The techniques described herein can be configured to account for thefact that TSLs (e.g., traffic lights, stop signs) and LSLs (e.g.,parking lots), often have more than one direction of approach. Forexample, knowing the direction in which a vehicle traveled past orapproached a TSL can provide additional information which can, amongother things, be used to improve the accuracy and latency of thetrip-end determination, e.g., if a device in a trip crosses a TSL, e.g.,from south to north and then, after 100 m, stops, it is more likely tobe at an actual trip end than a vehicle that approaches the TSL from thenorth, and stops 100 m north of the TSL but has not yet crossed it.

The described techniques can be further configured to define/associatelocations as TSLs (or non-TSLs) only under or during specificconditions. For example a certain location may only exhibit behavior asa TSL during certain times of days/days of week (e.g., during weekdayrush hour), during certain climatic conditions (e.g., rain, snow) orduring certain traffic conditions (e.g., real-time traffic conditions asprovided by various mobile applications and/or road infrastructure).

For example, an application that does not account for TSLs/LSLs, may beconfigured to lift/modify a selective restriction (e.g., on driverdevices) after the device has been determined not to have been in a tripfor 2 minutes. The result is that a driver who has permanently endedhis/her trip will continue to be restricted from utilizing his/herdevice (e.g., in one or more ways that pertain to such restrictions)until 2 minutes have elapsed (a potentially frustrating result for manyusers) while a driver stopped at a red traffic light for three minutes(i.e., for a duration exceeding the referenced threshold) would be ableto access his/her devices during the latter part of the red trafficlight (and perhaps for some period of time point after the light changesand driving resumes), despite still being present in an active trip.However, in an application configured to determine/account for TSL/LSLs,if the device is determined to have stopped at an LSL, the selectiverestrictions implemented with respect to the device can belifted/modified faster, for example, after one minute (resulting in abetter experience for the user), whereas if the device is determined tohave stopped at a TSL, the selective restrictions implemented withrespect to the device can be lifted/modified more slowly, for example,after 3 minutes (resulting in a safer experience, both for the user andsociety). In a scenario where the device is determined to have stoppedat a location that is determined/identified to be neither a TSL nor anLSL (or cannot be determined to be a TSL or an LSL), a potentiallydifferent waiting period, for example, 2 minutes can be implemented.

Moreover, data originating from various sources (e.g., a database oftraffic lights locations or parking lots) can also be utilized indetermining/defining TLSs and LSLs, such as in conjunction with thetechniques described herein. It should be noted that the level of detailof the information that is available through such databases may notinclude things like the length of a light for travelers in eachdirection at different date/times. The speed at which new information isavailable may be higher with “field-determined” TSLs/LSLs using mobiledevices than will numerous, possibly-governmental databases.

Moreover, the various techniques described herein can be furtherconfigured to account for the fact that the locations of TSLs and LSLsmay change over time, e.g., new traffic lights are installed, parkinglots are built and destroyed etc. and the correspondinglocations/associations that pertain to such TSL/LSL locations can beadjusted dynamically over time, such as in a manner known to those ofordinary skill in the art.

The various trip-end detection techniques described herein can beimplemented with respect to parking assistance applications, whereby adetermination as to whether a stop has occurred at a TSL (or an LSL) canenable a further determination as to whether a user has parked (and, forexample, record and/or dissemination such a parked location [e.g.,reflecting that one less space is available in a parking lot] and/orinitiate payment arrangement for such parking) or whether such a userhas just stopped temporarily in which case one or more of suchdeterminations/functions may not be appropriate.

At 5340, content (e.g., sponsored content such as advertisements), suchas content pertaining to a geographic location (e.g., the geographiclocation with respect to which the inputs received at 5310 areassociated) can be identified. In certain implementations, such contentcan be identified based on a determination (such as at 5320) that theincidence of deceleration is relatively likely to be maintained for arelatively longer time duration.

At 5350, content (such as the content identified at 5340) can beprovided. In certain implementations, such content can be provided at,on, and/or in relation to a device (such as the device with respect towhich the inputs were received at 5310). Moreover, in certainimplementations such content can be provided based on a determination(such as at 5320) that the incidence of deceleration is relativelylikely to be maintained for a relatively longer time duration, such asis described herein.

By way of illustration, determining whether a stop has occurred at a TSL(or an LSL) can enable the providing of more appropriate/targetedadvertisements (e.g., to the user). For example, a user determined tohave stopped permanently may be relatively more interested in diningopportunities in the area in which they stopped, whereas the same wouldbe far less appropriate (and perhaps even distracting and dangerous) fora user who has only stopped temporarily.

In addition, long term trip ends can also be determined/assumed to haveoccurred if the user initiates one or more actions with respect toparking (e.g., user pays for parking with app) or can be determined tobe likely to soon occur (e.g., user looks for parking with app, usernears the location in which she has reserved a spot), such as if theuser engages a parking application on the mobile device (e.g., launch,bring to foreground, reserves a space) and/or depending upon whatactions that user takes in such application.

It should be noted that, in certain implementations, TSLs and/or LSLscan have different degrees/magnitudes. For example, at some TSLs (e.g.,a long red light), the time that a device spends at or near thatlocation is relatively longer (e.g., 5 minutes), whereas at other TSLs(e.g., a short red light) the time the device spends at/ear thatlocation is relatively shorter (e.g., 30 seconds).

Moreover, in certain implementations, in addition to (and/or instead of)determining or ‘learning’ the referenced TSLs and LSLs (e.g., usingmachine learning techniques as are known to those of ordinary skill inthe art), the user (or another person knowledgeable about the user'stravel patterns, e.g., an employer) can provide various input(s) as toone or more such locations at which she often makes LSLs (e.g., homedriveway, work parking lot, etc.) or TSLs and device restrictions can bemodified based upon the presence of the device in or near such one ormore locations (e.g., as determined by GPS, WiFi access points or othersignals) and, in certain implementations, further in conjunction withother inputs (e.g., speed, motion, etc.). For example, one or morerestrictions employed on a device that was previously determined to bein a trip can be relaxed upon determining that the device is in (ornear) the work parking lot (where the work parking lot is contained inthe list of user input LSLs) and the device is moving at less than 10km/h for 15 seconds.

In certain implementations, a device can be determined to be at an LSLwhen (or just before, or just after) it enters a region that is known tobe an LSL for that user and/or for a group of users. By monitoring thelocation of the device relative to LSLs and dynamicallythrottling/adjusting such monitoring (e.g., frequency, intensively,sensor(s)/radio(s) used) based upon the distance that the device is froman LSL (and/or the likelihood that the device will enter an LSL soon),the amount of power used to enable the device to determine that it isentering (or is about to enter or has just entered) an LSL“just-in-time” can be greatly reduced. For example, if a device is 10kilometers from its nearest known LSL, and the estimated time to reachthe nearest LSL is 15 minutes, there is no need to check if the deviceis near the LSL for, perhaps, 14 minutes. The check at 14 minutes can bedone with a low power sensor (e.g., cellular radio, WiFi scan) to seehow the device has progressed relative to the LSL. In certainimplementations, if the device is nearing the LSL, a more accurate,higher power consuming sensor (e.g., GPS) can be turned on so that, whenthe device stops and is in an LSL one or more device restrictions can bemodified immediately.

In certain implementations, an interface indicator/notification can bemade visible or otherwise enabled when a one or more condition(s) havebeen met (e.g., the device/vehicle is determined to be moving at a lowspeed, short distance, with few/small WiFi changes, cell tower changes,etc.). Such an indicator/notification can, for example, notify or informthe user of the amount of time remaining until one or more restrictions(such as those that were employed based on a determination that the userwas driving/the vehicle was moving) will be relaxed, removed, etc. Incertain implementations, such an indicator/notification may not bevisible or may be disabled when one or more condition(s) are met (e.g.,high speed, long distance, many/large WiFi changes, cell tower changes,etc.).

It should also be noted that the methods contained above may consist ofthe device also using information from vehicle data system 164 (e.g.,OBDII), e.g., the speed of the vehicle and/or the gear in which thevehicle is engaged.

It can be appreciated that, in certain scenarios, one or more‘trade-off(s)’ or compromise(s) may need to be made with respect to howto process determinations pertaining to temporary stops/slow-downs inmovement in order to determine when a device is in a moving vehicle andthereby selectively restricting functionality of the device on thatbasis (i.e., should the trip be determined to be over, in which case theselective restriction should be removed, or is the vehicle stopped, suchas at a red light, in which case perhaps the selective restrictionsshould not be lifted). It can be further appreciated that implementing a‘timeout’ period (e.g., determining that a trip is over after adetermination that a device has not moved for X minutes) can entailcertain shortcomings. For example, drivers who have ended their trip andwant to use their devices prior to the end of X minutes will befrustrated with such a restriction and drivers who are still withintheir trip, and who are stopped/moving slowly for more than X minutes(e.g., heavy traffic, long light) may nevertheless be able to use theirdevices which is dangerous/illegal.

Accordingly, in certain implementations an “honor system” can beemployed, whereby drivers can self-declare their trips to have ended byproviding/inputting such a declaration/indication to the device (e.g.,via touch, voice, visual (e.g., gesture), shake etc. input), based uponwhich one or more restrictions can be modified, eased, or otherwiseremoved from the device without having to wait until a determination ismade that the device is static/slow for a certain period of time.

If, however, a determination that the device is present within a trip ismade within a certain period of time after the referencedself-declaration of a trip end is received, the user of such as deviceand/or the device itself can be given/ascribed a “strike.” Uponaccumulating more than a certain number of strikes, the referencedself-declaration mechanism/technique can be disabled or otherwise ceaseto work (or will be made to work less effectively), such as with respectto the particular user and/or the particular device. Moreover, incertain implementations the referenced “strikes” may subsequently becanceled or otherwise “evaporate” based on different events (e.g., thepassage of a certain amount of time, such as each strike expiring oneweek after it is created, the travelling of a certain distance—eachstrike expires 10 driving hours after it was created), etc.

In another implementation, a driver who has completed a trip canself-declare a trip to be over (such as in the manner described above),and such a self-declaration can cause an immediate (or shortlythereafter) determination to be triggered by acquiring sensorinformation and/or other information to determine, as soon as possible,whether or not the trip has ended (i.e., sooner than would otherwise bedetermined using various other techniques). Such a feature can beadvantageous, for example, in settings where, in an attempt to savepower, the various data acquired to determine whether or not a trip hasended are acquired with latency (e.g., with delay, in duty cycles)and/or at less than the fastest sampling rates possible. Accordingly, byacquiring one or more of the referenced data items relatively morequickly (such as upon receiving an indication, such as from a user, thatthe trip has concluded) one or more of the determinations that can bemade in order to lift/remove the referenced selective restriction(s) canbe initiated relatively faster/sooner. Stated differently, suchtechnique(s) can enable ongoing power-saving techniques to be appliedmore readily while reducing the degradation to the user experience.

In another implementation, a similar technique can be used to allow auser to cause the device to immediately (or relatively more quickly thatit would ordinarily have) re-check or re-query whether or not it is in atrip. Such a technique can be advantageous, for example, in situationsin which the device was determined to be present within a trip when, inactuality, it was not (false positive) and/or in situations in which thedevice was determined not to be present within a trip when, inactuality, it was (false negatives).

Moreover, upon determining that a device is present within a trip, itcan be advantageous to apply different (or asymmetric) methods todetermine whether or not the trip has ended, such as based upon whetherthe device is being operated by a driver or a passenger. For example,the trip detection techniques (such as those described herein) employedwith respect to devices determined to be operated by passengers can beeased relative to devices determined to be operated by drivers. Forexample, power can be saved by lowering the rate at which one or moresensors (e.g. GPS, accelerometer, cellular, Wifi, BT radios, etc.) on adevice determined to be operated by a passenger are sampled in order todetermine whether a trip has ended. It can be appreciated that adding alatency aspect to the detection of a trip end is not generally painfulto passengers who have so authenticated because their devices do nothave selective restrictions employed (or are relatively less restrictedthan devices determined to be operated by drivers).

In certain implementations, inputs originating from one or more lowpower sensors (e.g., accelerometer, gyroscope, etc.) of a device can beprocessed to determine an activity state of a device (e.g., stationary,walking, in-vehicle, etc.), such as based on one or more trends,patterns, etc., that can be identified within the various input(s). Tothe extent that an activity can be recognized with sufficiently highprobability, one or more restrictions associated with such activity canbe applied to and/or in relation to the device. To the extent that noactivity can be recognized with sufficiently high probability, and, inparticular, if it cannot be determined with sufficiently highprobability whether or not the device is present within a vehicle, oneor more additional sensors and/or radios and/or the same low powersensors sampling at higher rates (e.g., Win radio, GPS radio,accelerometer at higher sampling rate) can be activated, and inputsoriginating from and/or determined with respect/in relation to suchsensors, etc., can be processed to determine whether the device ispresent within a vehicle and, based upon such determination, one or morerestrictions associated with such activity can be applied.

It can be appreciated that, in many cases, inputs originating from thereferenced low power sensors are likely to be sufficient to make suchdetermination. However, in certain scenarios such a determination cannotbe made with sufficiently high probability. For example, in a scenarioin which a user is sitting and holding the device in his hand, e.g.,engaged in a FaceTime conversation, it can be appreciated that thedevice is unlikely to be determined to be stationary, as it is movingduring the conversation, and is also unlikely to be determined to beengaged in walking, and even if it were in a vehicle, any signals/inputsoriginating from the accelerometer indicating that the device was in avehicle are unlikely to be detectable over the noise introduced by theuser's movement of the device (low SNR). In such a case, for example,inputs originating from the use of additional sensors (e.g., Win radio,GPS radio, etc.) can provide information to determine with higherprobability whether the device is present within a vehicle.

It should be noted that inputs originating from one or more motionsensors (e.g., accelerometer, gyroscope, etc.) can be processed toeffectively identify trip starts (or trip stops) because the length oftime for which the device sustains acceleration (or deceleration) duringa vehicular trip start (or trip stop) (which may be for 20 seconds ormore, in some vehicle classes), generally exceeds the length of time forwhich sustained acceleration can occur in any human-powered activity.

In another approach, the mobile device of a driver will, on average,display larger movements than that of a passenger measurable by sensors145 of mobile device 105 due to the fact that the driver is likely to beholding the mobile device 105 in only one hand, whereas a passenger ismore likely to be using both hands to hold a mobile device 105, or iscapable of increased focus even when using only one hand to operatemobile device 105. This can preferably be done by taking the Fouriertransform of a 3D acceleration function and integrating it (squared,i.e. L2-norms) over N disjoint frequency intervals, as is well known tothose of ordinary skill in the art. The resulting 3N numbers arepreferably a “signature”. The signature corresponding to a driver can bedistinguished from that of a passenger using a classification algorithm,such as SVM, which has preferably been trained on sufficiently largepre-classified signature bank, as is also known to those of ordinaryskill in the art.

GPS—GPS 145C of mobile device 105 can be used, preferably, in certainarrangements, in conjunction with other sensors, to identify thein-vehicle position of mobile device 105. In certain arrangements thisis achieved in part based on knowledge of the lane boundaries of theroad on which the vehicle is driving (based on map data orcomputation/observation), together with a determination of mobiledevice's 105 location, using GPS 145C, to be on the right or left sideof such lane. If mobile device 105 is in the left part of its currentlane, then it can be determined to be on the left side of the vehiclewithin which it is traveling, while if it is in the right part of itscurrent lane, then it is on the right side of the vehicle. Such in-lanelocation calculations can further be averaged over time to increase theaccuracy of the location of the mobile device 105 within its thencurrent lane and, as a result, the accuracy of the determination of thelocation of mobile device 105 inside the vehicle.

It should be understood that the term “turn” as used herein can refer toa turn or any angle and/or curvature and/or any change in lateralacceleration and/or gyroscopic yaw, no matter how large or small and thecomparisons described above can be applied discretely or continuously.It should also be appreciated that such inputs can be perceived atpractically any time and/or interval, even those that do not necessarilycorrespond to “turns” as conventionally understood, and such inputsshould be understood to be within the meaning of the term “turns” asused herein.

It should be understood that the term “bump” as used herein can refer toa change of any size in the upward acceleration, irrespective ofpositive or negative change and irrespective of how large or small andthe comparisons and filtering described above can be applied discretelyor continuously at regular or irregular sampling rates.

Magnetic Field—A vehicle's metallic and electrical parts influence themagnetic field in the vicinity of and inside such vehicle. A 3-axismagnetometer 145E of mobile device 105 can be used to detect theseinfluences by measuring such magnetic field(s) at various times beforeand during a vehicle's operation (e.g., a car that has not yet beenstarted will have a different magnetic signature than one in which theelectric systems are operating) and by comparing them with knownmagnetic signatures of different in-vehicle locations in order todetermine the in-vehicle location of mobile device 105. Such signaturescan be universal and/or can depend on additional parameters such asvehicle model, vehicle location, etc.

For example, the major metallic component in most vehicles is the motorand in most vehicles (e.g., cars, buses), and it is normally situated inthe front part of the vehicle, near the center. The magnetic fieldsensed by magnetometer 145E of mobile device 105 can be compared withthe magnetic field that is otherwise present absent the magneticdisturbances—thereby indicating the direction of the motor. The lateralcomponent of that direction is preferably the opposite of the left-rightin-car location of mobile device 105.

User Baseline vs. Population Baseline—As described in detail above, suchas with respect to step 224, in the identification of many of the userdetermination characteristics described above, the values and signaturesmeasured on and/or computed with and/or in relation to mobile device 105are compared to baseline values (which are preferably stored in one ormore databases 174, 162) in order to determine if mobile device 105 isthat of a driver or a passenger. In certain arrangements, such baselinevalues can be independent of the user (e.g., the standard deviation ofthe time between keystrokes for all people in the country using aparticular model phone), while in other arrangements such values can beuser dependent (e.g., this mobile device 105 (or this user of thismobile device 105, if such is available) usually texts at 100 charactersper minute, currently he is texting at the rate of 10 characters perminute—thus the person holding it is likely driving).

Example 2

As noted above, such as at steps 222 and 223, considering multipleinputs can increase the accuracy of one or more of the determinationsdescribed herein, such as the determination of an in-vehicle role of auser of a mobile device 105, 160. This advantage is further illustratedabove at steps 225 and 226, wherein inputs from multiple devices areconsidered in order to compute such determinations. Furtherillustrations of such inputs/determinations include, but are not limitedto:

In-Vehicle Location—In the United States and in most other countries inthe world, drivers are the left-front most occupant in a vehicle,relative to the front end of the vehicle. By identifying whether aparticular mobile device 105, 160 is or is not the left-front mostdevice within a vehicle, a determination can be made that such device105, 160 is or is not being operated by the driver.

It should be understood that the referenced in-vehicleidentification/determination is preferably achieved in conjunction withcommunication between mobile device 105 and one or more of mobiledevices 160, whether through direct communication or through network166. It should also be appreciated that in certain arrangements suchidentification(s)/determination(s) can be performed in a server-sideconfiguration, while in other arrangements suchidentification(s)/determination(s) can be performed in a client-sideconfiguration. In one such server-side configuration, one or moresoftware modules 130 are preferably executing at the various mobiledevices 105, 160. One or more of the modules configure the each of therespective devices 105, 160 to transmit its absolute locationcoordinates (such as those provided by GPS 145C and/or an inertialnavigation system (INS) and/or its relative location (e.g., 3 metersfrom Win device #1234) to central machine 168. Central machine 168 canthen process the various locations coordinates and/or relative locationsreceived from the various devices 105, 160 in order to determine whichof the various devices 105, 160 are sufficiently close to one another,over a period of time (e.g., 1 minute, 1 hour, etc.), based on which itcan be determined that such devices 105, 160 are present within the samevehicle. In a client-side configuration, the mobile devices 105, 160communicate between one another (such as through communication interface150), exchanging absolute location and/or relative location anddetermining which other devices 105, 160 are in within the same vehicle,substantially in the manner described above with regard to theserver-side configuration. By way of further example, in certainarrangements one of devices 105, 160 can emit a tone and/or signal (suchas an audio tone), and only those devices 105, 160 that perceive theemitted tone are determined to be within close proximity of the devicethat emitted the tone.

In both server-side and client-side configurations, upon determiningwhich mobile devices 105, 160 are within a particular vehicle, sensordata (that is, data originating at one or more of sensors 145, such aslocation coordinates from GPS 145C, or lateral accelerations during aturn) from the various devices 105, 160 can be compared with one anotherto determine a relative in-vehicle location of one or more of thedevices 105, 160. Such relative location can be subsequently filtered togenerate a real-time driver-passenger determination, providingincreasing accuracy in driver/passenger identification.

Driver-Anticipatory Movements—The driver of a vehicle is generallybetter able to anticipate the movements of the vehicle he/she is drivingas compared to the passengers because the driver is the initiator ofmany of the movements that the vehicle undergoes, and can thusanticipate the forces that are created as a result of the vehicle'smovement. Such predictive actions can be detected by one or more ofsensors 145 of mobile devices 105, 160 (e.g., accelerometer 145A and/orgyroscope 145B), and can be further processed to identify whether aparticular mobile device 105, 160 is being used by a driver or apassenger. A driver instinctively tenses and/or flexes certain ofhis/her muscles to adjust for the vehicle movements that are about tooccur on average, more adroitly (less sudden with less corrective bodymovement) and more quickly than a passenger does. By way ofillustration, a driver anticipates and compensates for the forcesexperienced during a turn quicker and more accurately than a passengerin the vehicle does. Similarly, a driver anticipates and compensates forthe forces experienced during sharp deceleration (braking) more quicklyand more accurately than a passenger. A driver also anticipates andcompensates for the forces of a lane change more quickly and moreaccurately than a passenger. By way of further illustration, the drivercan be thought of as a dampening system which performs better than acorresponding “passenger” system, due to the driver's higher degree ofconsciousness, awareness, and/or anticipation. In one arrangement, oneor more of the listed effects/phenomena can be detected/identified byprocessing one or more inputs from one or more sensors 145, such as bymeasuring the change in acceleration (i.e. the L2 norm of the derivativeof the acceleration) over the relevant time window. In this case theacceleration is preferably further band-pass filtered to focus only onfrequencies relevant to this determination, and to further exclude otherdriver-acceleration effects (e.g., hand-shaking, etc.) as discussedherein.

Magnetic Field: A vehicle's metallic and electrical parts influence themagnetic field in the vicinity of and inside such vehicle. Inputsoriginating at a 3-axis magnetometer 145E of a mobile device 105, 160can be used to detect and determine these influences by processing suchinputs to determine a magnetic field at various times before and duringsuch vehicle's operation (e.g., a car that has not yet been started willhave a different magnetic signature than one in which the electricsystems are operating) and by comparing them with known magneticsignatures of different in-vehicle locations in order to determine thein-vehicle location of such device 105, 160. The presence of two or moredevices within a single vehicle can influence each other's magneticreadings in a way that can be determined based on their comparison. Itshould be understood that in certain arrangements, such signatures areuniversal while in other arrangements they depend on additionalparameters such as vehicle model, vehicle location, etc. In addition,comparing the magnetometer 145E inputs from more than one mobile device105, 160 located within the same vehicle can enable a more accuratedetermination of the in-vehicle location of one or more of such devices.

Example 3

As noted above, the processing of the various inputs discussed herein ispreferably enhanced by incorporating various additional processingoperations which serve to further enhance the accuracy of thedeterminations that are made. Examples of such further processingoperations include, but are not limited to:

Clock synchronization—As noted above, in arrangements where inputsoriginating from multiple devices 105, 160 are processed together (suchas several of those referenced above in EXAMPLE 2), it is preferablethat simultaneous timing measurements originating at the respectivedevices 105, 160 are compared as well. In one arrangement, this can beeffectively achieved by synchronizing the internal clocks of therespective devices 105, 160. By way of illustration, a relativedisplacement can be estimated, and this estimate can be used to processall relevant inputs such that they are synchronized to the same clock.

Examples of such synchronization methods include: (A) processing timeinputs from GPS 145C to compute a mean time displacement between GPSclock and each the clock of each device 105, 160. The difference betweenthose displacements can be determined to be the displacement between thedevices. (B) Configuring one of the devices 105, 160 to emit a sound andreceiving the sound at a second device (such as at microphone 145D), andfurther noting the time the respective events occurred at each device(that is, the time of the emitting of the sound and the time of thereceipt of the sound) and then repeating same process in reverse. Thenoted times can then be subtracted from one another, reflecting the timethat it takes to the sound to travel, and such values will cancelthemselves out, leaving twice the relevant time displacement remaining.

Orientation Detection—In discussing the processing of various inputs,such as those of accelerometer 145A and other sensors 145, it ispreferably that various inputs be identified and/or separated intoelements such as “forward acceleration”, “lateral acceleration” andsuch. These terms are relative to the car's coordinate system (e.g.“forward” is the direction of car's movement) while the raw inputs fromthe various sensors 145 are relative to the coordinate system of amobile device 105, 160 (it should be understood that while the presentexample is described with respect to a car, substantially similarapproaches can be applied to other vehicles as well). In order totransition (rotate) such inputs, the relative orientation of the mobiledevice 105, 160 within the coordinate system of the car is preferablyestablished. The following figures depict the various relativecoordinates of mobile device 105, 160, of a car, and of a mobile device105, 160 within a car:

FIG. 9A depicts the relative coordinate system of mobile device 105, asis known to those of ordinary skill in the art and referenced herein.

FIG. 9B depicts the relative accelerations and gyroscopic rotations of amobile device, as is known to those of ordinary skill in the art andreferenced herein. It should be understood that although mobile device105 is not shown in FIG. 9B for the sake of clarity, the variousrelative acceleration and rotations shown in this figure are relative toa mobile device in the same position as that shown in FIG. 9A.

FIG. 9C depicts the gyroscopic sign convention used herein, as is knownto those of ordinary skill in the art and reference herein.

FIG. 10 depicts the coordinate system used in relation to a vehicle(such as at vehicle data system 164) as is known to those of ordinaryskill in the art and reference herein.

FIGS. 11A-B depict mobile device 105 and its respective coordinatesystem in relation to a car and its respective coordinate system. Forexample, as will be described in greater detail below, in certainarrangements the respective coordinate systems can be transitioned, suchthat it is recognized, for example, that the +Z coordinate of the carcorresponds to the +Y coordinate of the mobile device 105, and the +Ycoordinate of the can corresponds to the −Z coordinate of the mobiledevice 105, as can be appreciated with reference to FIG. 11B.

Establishing the orientation of a mobile device 105, 160 within thecoordinate system of a car can be accomplished in a number of ways. Byway of illustration, in a ‘static’ approach, wherein it is assumed thatthe relative orientation of device 105, 160 is constant (e.g., if thedevice is attached to a cradle or is in the pocket of unmovingpassenger), the mean acceleration vector can be determined and beidentified as the “down” axis. The “forward” axis can be determined bycomparing/processing inputs from GPS 145C that correspond to directionangles with inputs from magnetometer 145E that reflect ‘north.’ Thethird axis can be computed based on the first two determined axes usingvector multiplication as is known to those of ordinary skill in the art.By way of further example, inputs from the accelerometer 145A, themagnetometer 145E and the GPS 145C (e.g., heading data) can be averaged,substantially in the manner described above.

In a dynamic arrangement, inputs originating at accelerometer 145A,gyroscope 145B and/or other sensors 145 can be processed to identifyreal-time changes in the orientation of a device 105, 160. In addition,acceleration/magnetic/GPS figures can be generated, preferably using“sensor fusion” algorithms, as is known to those of ordinary skill inthe art. In doing so, the above-referenced “static” approach can beutilized to dynamically determine the relative orientation of the device105, 160.

It should be noted that the gyroscopic sign convention adopted herein ispreferably such that if an observer positioned on the positive part ofthe axis of rotation sees the rotation as counterclockwise, it is deemedto be positive.

Low-Pass filtering—The values derived and/or computed from the variousinputs originating at the various sensors 145 of mobile device 105, 160can be frequently compromised by the vibration(s) present in car'senvironment (originating at the car's engine, road bumps, imperfectwheels, wind blowing through the windows, or even car audio sounds).Such vibrations can inject “noise” into the inputs originating at thevarious sensors 145, and can adversely affect the precision of theprocessing of the various algorithms disclosed here, both in terms ofefficiency and final accuracy.

There are various ways that this problem can be addressed. In onearrangement, one or more of devices 105, 160 within the vehicle areattached to a dampening device. In certain arrangements such a dampeningdevice can include one or more weight(s) that can be attached to themobile device 105, 160 to effectively increase its mass and thus make itmore vibration resistant. Additionally, dampening materials (e.g.sorbothane pads) can be attached to a device 105, 160 to prevent highfrequency vibrations from passing to the mobile device 105, 160. In anyevent, the inputs can be preferably processed with a bounded passfilter. On such example is an FIR with 128 taps with Hamming windows.

Sensor Fusion—As has already been noted and illustrated above, variousdeterminations can be made by processing inputs from several sensors 145together (e.g. forward velocity inputs originating at both theaccelerometer 145A and GPS 145C).

Example 4

The following scenarios illustrate additional examples of the analyzingof a first and second input and identifying the presence of a first userand a second user (such as at step 720, above):

Using one or more biometric authentication methods (as are known tothose of ordinary skill in the art) to identify the presence of a firstuser and a second user. Such biometric authentication methods include,but are not limited to, voice recognition, fingerprint recognition, facerecognition, DNA identification, and retina identification.

The following are further examples of restrictions that can be employedat a mobile device 105, such as in the manner described in detail abovewith reference to FIG. 7. Various of these examples impede operation ofmobile device 105 by a driver more so than they impede operation of thedevice by a passenger:

-   -   (a) If talking, the device is restricted to being held on the        left side (right side for U.K.) of the head/face of the user and        with an upright orientation, so that driver usage cannot be        hidden from external observers.    -   (b) If texting, mailing, browsing etc., mobile device 105 is        restricted to operating when having straight orientation (no        yaw) (adjustment can be necessary, in certain arrangements, for        a vertical/horizontal keyboard) and at least close to upright        orientation (cannot be on knee or low down so that driver cannot        “hide” the device use from external observers).    -   (c) The device interface will only function horizontally (more        difficult for driver to use).    -   (d) The device 105 is restricted to operating in one or more        ways only when camera 145F perceives a frequently moving        background (e.g., be held high, not hidden low in the driver's        lap or blocked by the steering wheel).    -   (e) The device 105 is restricted to operating in one or more        ways that can be determined to correspond to operation by a        passenger (and/or correspond to operation by a passenger of a        particular device), such as the various determinations described        in detail herein. By way of example, if no correlation (or,        alternatively, no negative correlation) is identified between        various typing tendencies and the speed, acceleration, and/or        maneuvering of a traveling vehicle, and/or a certain typing        accuracy threshold it met and/or maintained over a period of        time, it can be concluded that the user is likely a passenger.    -   (f) The device 105 is restricted to operating only when it can        be determined based on one or more inputs that the device is        under the control of a passenger and/or under the control of a        passenger using this particular device, such as the various        determinations described in detail herein. By way of example, if        relatively little “shake” is perceived at mobile device 105 over        a period of time, it can be determined that the device is under        the control of a passenger, as a passenger has the ability to        control “shake” by using both hands to steady the device—an        option not always available to drivers who generally need their        second hand to steer the vehicle.

It should also be understood that the various restrictions referencedherein can also be dependent upon the presence and/or absence of certainof the determinations disclosed herein. Thus, for example, variousrestrictions can be employed only when a device cannot be definitivelydetermined to be in the rear or on the right side of a vehicle (thussuggesting that a driver can potentially be operating the device).

Example 5

In determining vehicle class or type, in certain arrangements adetermination is made as to whether one or more mobile devices 105, 160is/are present and/or in use in a vehicle. If such a determination isaffirmatively made, a further determination can then be made regardingthe general type or class of the vehicle (e.g., motorcycle, car, bus,train, boat, plane, etc.). This determination can then be used tofurther determine if there are restrictions on the mobile device usageon the part of a driver or the passenger in the vehicle. For example, ifit is determined through a signature analysis (that is, an analysis ofvarious patterns in various inputs) of an accelerometer 145A and/orgyroscope 145B and/or GPS 145C of mobile devices 105 and/or 160 thatthere is a high-likelihood that a particular mobile device 105, 160 islocated on a train, then that the mobile device 105, 160 can remainfully operational without any operation state restrictions (assumingthat no restrictions apply to anyone on the train including theconductor). If however, it is determined that a mobile device 105, 160is being used within a car, restrictions can be applied (e.g., no phoneuse at all or just no texting), particularly if it is determined thatthe user of the mobile device 105, 160 is the driver of the car, and nota passenger.

As described in detail above, the type or class of vehicle in which amobile device 105, 160 is located can preferably be identified and/ordetermined by using one or more of sensors 145 of mobile device 105. Incertain arrangements, this identification/determination can be improvedby using the onboard sensors of other mobile devices 160 and/or theonboard sensors (e.g., vehicle data system 164) of the vehicle in whichmobile device 105 is traveling. As noted above, being that differentvehicles operate in perceptibly different ways (which, in turn, reflectdifferent patterns that are perceptible to one or more of sensors 145),the signature of one or more of sensors 145 of mobile device 105 (and/orother mobile devices 160) present and/or used in relation to each of thefollowing vehicles is identifiable within a certain degree of accuracy:

It should be understood that in certain implementations, a device can beauthenticated (e.g., determined to be likely to be operated by a userwho is a passenger) if it can be determined that the user of the deviceis able to perform one or more actions (such as providing certaininputs) and/or demonstrate/provide evidence of certain situations (suchas providing photographic/videographic documentation of such situations)that a user who is simultaneously driving a vehicle would not bereasonably capable of doing. As described in detail herein, examples ofsuch methods of authentication include: if, while having determined thatthe vehicle (within which the mobile device is present) is in motion,the user of the device can be determined to be capable of (a) performingan action in a different part of the vehicle (such as in an area of thevehicle where the driver could not reasonably sit and/or reach); (b)holding his/her look/gaze (i.e., maintain focus of his/her eyes) in adirection (such as towards the mobile device) that is not towards theroad ahead, for a defined/sufficiently long period of time; (c)using/interacting with the device with two hands for a sufficiently longperiod of time/performing one or more tactile gestures that requiresubstantially simultaneous use of both hands of the user (it should benoted that the terms “tactile gesture” and “tactile gestures” as usedherein are intended to encompass inputs and/or interactions that areprovided by a user in a tactile manner, such as through physicalinteraction with one or more media, elements, and/or components with oneor more fingers or hands of a user, examples of which including pressingbuttons, and performing gestures such as taps, swipes, and/or other suchinteractions with a touchscreen or touchpad); (d) configuring the deviceto record a visual capture (e.g., take a picture or video) within whichone or more indicators (that is, elements or aspects that can beperceived within the visual capture) that would be difficult/impossiblefor a driver to capture, are present (examples of such indicatorsinclude: (i) the presence of a passenger's seatbelt, as describedherein, (ii) the presence of a steering wheel with two hands on it, asdescribed herein, (iii) the presence of the eyes/face/smile etc. of theuser, as captured from below, above, and/or from the side (it can beappreciated that in scenarios where there is little or no external lightother than the interior overhead lighting of the vehicle, such as atnight, it can be preferable to take a picture from above and/or from theside, such that the overhead interior lighting within the vehicle doesnot interfere considerably with the visual capture) wherein the steeringwheel of the vehicle is not present in the visual capture, and/or (iv)the presence of the feet of the user in a position that isdifficult/impossible for a driver to achieve, etc.), etc.

As described herein, in certain implementations, the device user can beprompted to provide one or more inputs in order to authenticate thats/he is a passenger. Examples of such authentication methods/approachesinclude performing an action or a set of actions, such as providing oneor more alphanumeric inputs in response to a CAPTCHA prompt (as is knownto those of ordinary skill in the art), providing one or more inputsduring the course of interacting with a game, providing one or moreinputs in attempting to solve a puzzle, a lock screen, etc. It can beappreciated that such authentication approaches/methods can beconfigured to require a significant degree of concentration (and/orprolonged concentration) on the part of the user, such that suchauthentication approaches/methods are too difficult to be successfullyperformed (and/or consistently successfully performed) by a driver of amoving vehicle (who, presumably, must concentrate on the road ahead).Such authentication approaches/methods can be further improved byconfiguring them to require that (a) the authentication can only besuccessfully completed (e.g., authenticating the user of the device asthe passenger) when the user uses both hands simultaneously (asdescribed in detail herein); and/or (b) the authentication can only besuccessfully completed when the required inputs are provided such thatthe user cannot simultaneously see the road ahead while performing theauthentication (such as by making the user tilt his/her head and/or eyesdown or up or right or left, e.g., by requiring that the device be heldflat and/or placed in the user's lap or on the seat between the user'slegs, as described herein, and/or by requiring that the user lookdirectly in to the device in the manners described herein).

In another implementation, in order to provide the necessary inputs inorder to authenticate the mobile device (e.g., to authenticate a user ofthe device as a passenger in a vehicle), various restrictions canconfigure the mobile device to require that the device be placed or heldflat (such that the z-accelerometer of the device indicates theapproximate value of gravity, e.g., when the device is positioned in theuser's lap or on the seat between the user's legs), and user tiltshis/her head so that the camera(s) of the device can detect the eyes,gaze, face, and/or smile etc. of a person (not necessarily limited to aparticular person), preferably for a certain minimum period of time(controlling, in certain implementations, for blinking and similareffects). It can be appreciated that such authentications can beachieved using a forward-facing camera (e.g., a camera on the side ofthe device that the screen is on in contemporary devices, such as theiPhone 4S produced by Apple of Cupertino, Calif., USA, and as isdepicted in FIG. 15F, wherein 145F₁ corresponds to a forward-facingcamera and 145F₂ corresponds to a rear-facing camera) and/or arear-facing camera (e.g., a camera on the side of the device that thescreen is not on in contemporary devices such as the iPhone 4s producedby Apple of Cupertino, Calif., USA).

It should be understood that in certain implementations, theauthentication methods/approaches described herein can be configured toauthenticate a user of a mobile device as a passenger upon determiningthe presence of the eyes/gaze/face/smile of the user, such as fromwithin a visual capture, only when such a visual capture can bedetermined to have been recorded while the mobile device was positionedin a manner/orientation that precludes/prevents the user fromsimultaneously seeing/focusing on the road ahead. (It can be appreciatedthat a driver operating the mobile device would generally only becapable of positioning the device in a manner/orientation whereby thedevice is able to capture his/her eyes/gaze/face/smile etc. while theuser is also able to see some portion of the road ahead.) This can bedetermined by (i) searching, such as with image processing techniquesknown to those of ordinary skill in the art, for theeyes/gaze/face/smile etc. of the user within a field of view that issmaller than the camera's field of view; and/or (ii) by requiring theangle of incidence between the user's eyes/gaze/face/smile etc. and thedevice be as close to (or as far from) 90 degrees (indicating that theuser is directly facing the device) as desired, such as in the mannerdepicted in FIG. 15G; and/or (iii) requiring that the ratio ofhorizontal pixels to vertical pixels of the user's eyes/gaze/face/smileetc. is consistent with the ratio present when a user looks directlyinto the device (and/or that the number of horizontal pixels and/orvertical pixels of the user's eyes/gaze/face/smile etc. is consistentwith the number present when a user looks directly into the device), asis known to those of ordinary skill in the art.

Moreover, in certain implementations, the authenticationmethods/approaches described herein can be configured to authenticate auser of a mobile device as a passenger only if the user holds the devicewithin a certain range of distance from her eyes/gaze/face/smile etc. Indoing so, it will be difficult, if not impossible, for a driver tofraudulently authenticate him/herself as a passenger by attempting toauthenticate the device by holding the device close to his/her head suchthat the resulting visual capture recorded by the device does notcontain any part of the steering wheel (as described herein). Thedistance can be determined, for example, based on the number of pixelsin the eyes/gaze/face/smile etc., relative to the resolution of thecamera and/or relative to the angle of incidence and/or using otherdistance measurement techniques known to those of ordinary skill in theart.

In certain implementations, the authentication methods/approachesdescribed herein can be configured to authenticate a user of a mobiledevice as a passenger upon determination that the user performed (and/oris capable of performing) one or more actions/provided one or moreinputs that can be determined to require(s) the use of one or two hands(e.g., swipe gestures at a touchscreen, including one or more times)such as in an implementation utilizing a forward-facing camera is used,and/or requiring a user to press a touchscreen with one or more fingersand/or touch one or more buttons on the device, irrespective of whetherthe camera is rear-facing or forward-facing), such as is described withreference to FIG. 15A.

It should also be noted that in certain implementations, when performingthe referenced authentication, it can be useful to configure the devicesuch that the user is required to (a) hold the device at a certainorientation, e.g., in landscape orientation, thereby making it moredifficult for a driver trying to falsely authenticate/unlock the device(which would otherwise allow the driver to perform certain actions),and/or (b) to encourage the user to hold the device in such orientationby having the device's screen display in landscape mode (that is,displaying the user interface in landscape mode, as described in detailherein), regardless of whether the device is actually held in alandscape orientation. It can be appreciated that such a configurationis relatively less of a burden on a passenger, as described in detailherein.

As referenced herein, in certain implementations, the authenticationmethods/approaches described herein can be configured to authenticate auser of a mobile device as a passenger only if no part of a steeringwheel is present in a visual capture, such as a visual capture of aportion of the user.

It should also be noted that in certain implementations, during theauthentication process, the mobile device can be configured to providingaudio and/or vibrational/tactile feedback to the user (such as in thecase of a forward-facing or rear-facing cameras, whereby the user can bedirected/instructed as to how to tilt/orient the device/camera in orderto achieve the requisite angle required by the particular authenticationmethod, as described in detail herein) and/or visual feedback (such asin the case of a rear-facing cameras and/or a forward facing camera)during the authentication process. In doing so, the user can be providedwith guidance/feedback, as needed, in order to enable the user toachieve the requisite input (such as a particular visual capture) inorder to authenticate the device, as described herein. FIGS. 15D and 15Edepict various examples of visual feedback that can be provided to auser during authentication.

By way of yet further example, in certain implementations, upondetermining that a device is in motion (or otherwise determining that atrip has begun) (such as in any number of ways described herein, and asdepicted in FIGS. 15H and 15I), a user can be prompted or otherwisepresented with an interface that can enable the user to initiate anauthentication process, such as by interaction with a ‘slide to unlock’interface on a touchscreen, as shown in FIG. 15J. Upon successfullycompleting the ‘slide to unlock’ gesture, another interface can beprovided which incorporates/implements any number of variable inputtechniques. For example, a keypad (or keyboard, etc.) can be providedwhose position with respect to the touchscreen of the device can changebased on one or more inputs. By way of illustration, FIGS. 15K-15Pdepict how the position of a keypad on a touchscreen can change based onand/or in relation to the angle/orientation of the device (asdetermined, for example, based on the accelerometer and/or gyroscope ofthe device). As shown in FIGS. 15K-15P, the interface can be configuredsuch that the keypad is centered within the touchscreen when the deviceis held in a ‘flat’ orientation (as shown in FIG. 15Q and describedherein), while being positioned elsewhere on the screen (for example, ina manner that precludes a user from utilizing the entire keypad forinput) when the device is held in other orientations (as shown in FIGS.15K-P). As shown in FIG. 15Q, upon orienting the device in a ‘flat’orientation (and thus centering the keypad), the user can be prompted tohold their thumb (or another finger) in a specific region of thetouchscreen, such as in the manner described herein. Upon determiningthat the user is doing so (that is, maintaining his/her thumb/finger onthe specified region), the user can be presented with a sequence ofseveral numbers which are to be input into the keypad in order toauthenticate the user to the device as a passenger, as shown in FIGS.15R-T. Upon successfully inputting the presented sequence, the user canbe authenticated as a passenger and various aspects/functions of thedevice can be activated/unrestricted, as described herein. It should beunderstood that, in certain implementations, the sequence can allow forsome degree of user error (e.g., mistyping of the presented numericsequence into the keypad), while also preventing a user fromauthenticating in the event that the quantity of errors exceeds adefined threshold (as described herein). It should be understood thatthe described authentication sequence is exemplary and that any numberof modifications or adjustments or omissions to the sequence can beimplemented and are within the scope of the present disclosure. Forexample, instead of a keypad the user may be presented with a keyboardand a sequence of letters to input.

Moreover, in certain implementations, in lieu of requiring asubstantially ‘flat’ orientation (as shown, for example, in FIG. 15Q anddescribed herein), the referenced technique(s) can be employed inrelation to an orientation whereby the device is oriented, for example,such that the Y axis of the device (as shown in FIGS. 9A-9B anddescribed in detail herein) is substantially aligned with the directionthat the vehicle is traveling in, and the X-axis (as shown in FIGS.9A-9B) is aligned with the up/down of the vehicle (as shown, forexample, in FIG. 15C) or vice versa, i.e., with the Y-axis is up/downand the X-axis is collinear with the direction in which the vehicle istravelling. It can be appreciated that in order to achieve such anorientation, a user of the device will need to orient the device suchthat the user is facing towards the middle of the vehicle, or towardsthe side windows of the vehicle—but not towards the windshield (i.e.,the front) of the vehicle (thus preventing attempts by drivers tocircumvent such techniques by authenticating while diving). That such anorientation is consistent with the direction in which the vehicle istraveling can be confirmed, for example, based on a correlation of theGPS heading and the magnetometer/compass directional reading, asdescribed herein. Moreover, that such orientation is consistent with theX-axis up/down can be confirmed based on one or more inputs from thedevice's accelerometer, such as in the manner described herein. Itshould also be noted that while in certain implementations thereferenced techniques can be employed relatively consistently withrespect to the various users (i.e., the same or a comparable orientationcan be required of a user irrespective of whether he/she can bedetermined to be a driver or a passenger), in other implementations suchan orientation can be selected based on a determination as to whether aparticular user is likely to be a driver or a passenger (or adetermination as to whether such a user is positioned on the right sideor left side of the vehicle) as determined, for example, as describedherein. In such implementations, for example, the user can be directedto orient the device in a particular way (e.g., such that the user mustface towards the center of the vehicle in order to continue thereferenced authentication process). It should also be noted that thereferenced orientations are also exemplary and that any other suchorientation can be similarly implemented.

In another implementation, the referenced technique(s) can be employedin relation to a substantially ‘flat’ device orientation (as determined,for example, as described herein) and an orientation in which the Y-axis(or X-axis) of the device is oriented substantially up/down and theX-axis (or Y-axis) is substantially collinear with the direction inwhich the vehicle is traveling.

FIG. 58 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 5810, a degree of correlation between one or more of (a) an axis of adevice and a direction with respect to which a vehicle (within which thedevice can be determined to be present) is determined to be travelingand/or (b) an axis of a device and a direction with respect to theearth/ground can be determined.

At 5820, an authentication/verification option/task can be enabledand/or an authentication attempt can be approved, such as with respectto the mobile device. In certain implementations, such an option can beenabled/attempt can be approved based on a determination (e.g., at 5810)that the degree to which the one or more axes and their respectivedirection correlate (e.g., with respect to a direction that the vehicleis traveling and/or the ground) meets or exceed one or more definedthresholds.

By way of illustration, in certain implementations, a passengerauthentication task may require that the orientation of the device mustbe determined to be one in which its y-axis (or x-axis) is within acertain range of the vehicle's heading (e.g., as measured by comparingthe device's magnetometer with its GPS heading). In addition, in certainimplementations such an authentication task may require that thedevice's x-axis (or y-axis) be determined to be within a certain rangeof normal to the ground/earth (with respect to its roll and yaw). Forexample, in order to complete such an authentication task successfully,the device's positive (or negative) y-axis must be determined to bepointed within +/−20 degrees of the vehicle's heading and the device'spositive (or negative) x-axis must be determined to be pointed up with+10 to −20 degrees of normal to the ground (roll) and +/−5 degrees ofnormal to the ground (yaw), such as is shown in FIG. 50 (angles rangesnot shown).

It can be appreciated that a window whose forward-facing edge issubstantially vertical is indicative of a passenger window in most carsand is also prevalent in trains and buses. Moreover, the forward facingedges of windows of front seat occupants (drivers or passengers) are notsubstantially vertical. Accordingly, processing a visual captureprovided by one or more device camera(s) (whether captured actively by auser and/or passively) together with the heading of the vehicle and theorientation of the device (e.g., using GPS, compass, magnetometer,accelerometer) can be used to identify the presence of window(s), theirforward facing edges, as well as the degree of verticality of all orpart of the forward facing edge (which, as noted, can be used todetermine whether or not the user is likely to be a driver—or at leastpotentially a driver—or a passenger).

FIG. 47 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4705 a first visual capture can bereceived, such as from a first camera of a user device. At 4710, asecond visual capture can be received, such as from a second camera ofthe user device. In certain implementations, the second visual capturecan be received substantially concurrent with receipt of the firstvisual capture. At 4715, the first visual capture can be processed, suchas to identify a presence of a face within the first visual capture. At4720, the second visual capture can be processed, such as to identify apresence of a face within the second visual capture. At 4725, one ormore operations can be initiated, such as with respect to the userdevice. In certain implementations, the one or more operations can beinitiated based on (a) an identification of a face within the firstvisual capture and/or (b) an identification of a face within the secondvisual capture. In certain implementations, one or more restrictionsemployed with respect to the user device can be modified. In certainimplementations, a user of the user device can be identified as apassenger.

It should be noted that the techniques described herein can be employedin relation to and/or in conjunction with one or more passengerauthentication task(s) (including but not limited to numericinput-related tasks and video capture-based tasks, such as thosedescribed herein), including in scenarios where various otherelements/aspects/components (such as those described herein in relationto various passenger authentication tasks such as landscape orientation,thumb/multi-finger tasks etc.) are included/incorporated.

In another implementation, an authentication task can be employed suchthat the authenticator (e.g., a passenger) can be prompted to use acamera of the device (such as a rear-facing camera) to take a visualcapture that can be processed to identify the inclusion of the profile(or another angle shot) of another vehicle occupant's face/head (forexample, in lieu of a straight-on shot of the authenticator's face asdescribed herein). In addition, the authenticator can be required tohold the device such that the screen is substantially parallel tovehicle's side window(s) and/or in an orientation where the device'stouchscreen is facing the passenger's window. It can be appreciated thatin such an orientation a driver is relatively unlikely to be able totake such a picture. And, even in a scenario where the driver were socapable, one or more inputs originating at the device (corresponding to,for example, accelerometer movement, the centering of the visualcapture, etc.) can be processed to determine that such input(s) indicatethat a driver is likely to be attempting such an authentication task(and the authentication attempt can thus be denied). In addition, incertain implementations the referenced authentication task can alsoincorporate one or more of the other elements described herein (e.g.,landscape orientation, thumb/multi-finger tasks, number input tasks,etc.), thereby further reducing the likelihood that the referencedtask(s) can be performed by a driver, while also avoiding substantiallyincreasing the difficulty for a passenger to perform them.

In yet another implementation, an authentication task can be employedsuch that the authenticating user (e.g., a passenger) can be prompted touse the device's front-facing and rear-facing camera simultaneously (orin sufficiently close chronological proximity to one another and/orinterleaved) to take two visual captures, each of which can be processedto identify a presence of a human face/head (e.g., a driver and apassenger) therein. In addition, the authenticating user can be promptedto hold/orient the device such that the screen of the device issubstantially parallel to the vehicle's side windows and is alsopositioned in an orientation where the device's screen is facing thepassenger's window. In such a scenario, a driver is relatively unlikelyto be able to take such pictures. And, even in a scenario where thedriver were so capable, the one or more inputs originating at the device(corresponding to, for example, accelerometer movement, the centering ofthe visual capture, etc.) can be processed to determine that suchinput(s) indicate that a driver is likely to be attempting such anauthentication task (and the authentication attempt can thus be denied).In addition, in certain implementations the authenticating user can alsobe prompted to perform one or more of the other tasks, elements, etc.described herein (e.g., landscape orientation, thumb/multi-finger use,numeric input tasks, etc.), thereby further reducing the likelihood thatthe referenced task(s) can be performed by a driver, while also avoidingsubstantially increasing the difficulty for a passenger to perform them.

In yet another implementation, the authentication task can be employedsuch that the authenticating user (e.g., a passenger), can be promptedto use the device's front-facing and rear-facing camera simultaneously(or in sufficiently close chronological proximity to one another and/orinterleaved) to take visual captures, each of which can be processed toidentify a presence of a human face/head (e.g., a driver and apassenger) therein, whereby the front-facing camera (e.g., the user'scamera) provides a video capture that includes a substantiallystraight-on face/head shot. In addition, the authenticating user can beprompted to hold/maintain the position/orientation of the device suchthat that the screen of the device is substantially parallel tovehicle's side windows and is also positioned in an orientation wherethe device's screen is facing the passenger's window. In such ascenario, a driver is relatively unlikely to be able to take suchpictures. And, even in a scenario where a driver were so capable, theone or more inputs originating at the device (corresponding to, forexample, accelerometer movement, the centering of the visual capture,etc.) can be processed to determine that such input(s) indicate that adriver is likely to be attempting such authentication task (and theauthentication attempt can thus be denied). In addition, in certainimplementations the authenticating user can also be prompted to performone or more of the other tasks, elements, etc. described herein (e.g.,landscape orientation, thumb/multi-finger use, numeric input tasks,etc.), further reducing the likelihood that the referenced task(s) canbe performed by a driver, while also avoiding substantially increasingthe difficulty for a passenger to perform them.

It should be noted that in scenarios that incorporate video capture,similar imaging methods, and/or techniques can also be employed inconjunction with one or more cameras that are in communication with, butnot (necessarily) physically connected to the device (e.g., wearablecameras). It should be further noted that the techniques describedherein can be modified and/or adjusted accordingly to account for suchmodifications to the techniques described herein.

It should also be noted that, in certain implementations, variousaspects of the interface(s) depicted in FIGS. 15H-T can be configured tooperate (e.g., be presented on a touchscreen) specifically/only inlandscape mode/orientation. It can be appreciated that such anorientation can be more difficult for users who are drivers to interactwith, while being relatively easier for users who are passengers tointeract with.

Moreover, in certain implementations one or more time limits can beimposed on any/all of the elements/operations/steps in the referencedauthentication sequence(s). Additionally, in certain implementations,any number of elements, operations, steps, or aspects of the referencedsequence(s) can be configured to determine that a user is likely to be adriver or a passenger at varying/intermittent stages of the sequence.For example, a sequence can be configured to terminate upon adetermination that the device is not being held with at least a certaindegree of stability (as can be determined as described herein, such asbased on inputs from an accelerometer and/or gyroscope). By way offurther example, a sequence can be configured to terminate upon adetermination that the sequence (or any number of the steps/aspects ofthe sequence) is not completed within a defined timeframe.

It should also be noted that in certain implementations a user of amobile device can be authenticated as being a passenger even if thevehicle within which the device is present is not moving, e.g., byrecording a visual capture within which the driver's hand and thesteering wheel can be determined to be present, as described in detailherein.

In certain implementations, the authentication tasks/techniquesdescribed herein can include one or more oral/audio tasks (as can beprompted/instructed by the device) which can be perceived/detected byone or more microphone(s) of the device, optionally in conjunction withone or more other device sensors, and which can be processed/analyzed inorder to authenticate a user of the device as a passenger, for example.For example, the device can prompt/ask the user to hold his device withtwo hands in a flat orientation (as if it were lying flat on a table),in landscape mode, and speak a word that flashes/is presented on thedevice screen at some time over a 5 second time period. If the voiceinput provided by the user and perceived by the microphone(s) can berecognized as being the correct word that was presented (or within adefined margin of error from it), while the accelerometer/gyroscope ofthe device also recognize that the device was held flat/in the properorientation, while the touch screen recognizes that tactile contact wasprovided in one or areas of the device (e.g., corners of the devicescreen) s as instructed and in such a way that can be determined to belikely that the device was being held with two hands, the user can bedetermined to be (and authenticated as) a passenger.

Turning now to FIG. 15, a flow diagram is described showing a routine1500 that illustrates a broad aspect of a method for selectivelyrestricting operation of a mobile device 105 in accordance with at leastone embodiment disclosed herein. It should be understood that in certainimplementations, such selective restriction of a mobile device can beemployed in order to restrict operation of the device by a user who is adriver of a vehicle, while not restricting operation of the device (or,restricting operation of the device relatively less) by a user who is apassenger of a vehicle. Accordingly, it should be appreciated thatvarious of the determinations and identifications described herein aredirected towards one or more factors and/or aspects that are indicativein various ways of whether the user of the particular device is a driveor a passenger of the vehicle. Additionally, it should be furtherunderstood that the referenced method is preferably implemented insituations, scenarios, and/or settings where mobile device 105 ispresent within a vehicle, such as a moving vehicle. Various methods fordetermining a presence of the device within a vehicle and/or a movingvehicle are described in detail herein.

At step 1505, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs one or morerestrictions at mobile device 105 and/or in relation to mobile device105, substantially in the manner described above with respect to step705. It should be understood that in certain arrangements, suchrestriction(s) are preferably configured, on average, to impedeoperation of mobile device 105 by a user that is a driver more so thanthe restriction(s) impede operation of mobile device 105 by a user thatis a passenger, as described in detail herein. It should also beunderstood that a single restriction can be understood and/or configuredto be a combination and/or composite of multiple restrictions. It shouldalso be understood that in certain implementations the methods describedherein can be applied to a device that is already restricted, such as adevice that is configured, by default, to operate, in a restrictedstate.

At step 1510, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or moreinputs, such as one or more visual captures originating at mobile device105 and/or mobile devices 160 (e.g., from camera 145F), such as animage, a series of images, and/or a video, substantially in the mannerdescribed above with respect to step 710.

Then, at step 1520, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, processes atleast one of the visual captures (such as those received at step 1510)to identify one or more indicators within the visual capture. It shouldbe understood that the terms “indicator” and/or “indicators” as used incontext of the referenced visual capture(s) are intended to encompassone or more items, elements, and/or aspects that can be distinguished,determined, and or identified within a visual capture, as is known tothose of ordinary skill in the art. That is, it can be appreciated thatin processing the one or more visual capture(s), the visual captures(e.g., images and/or videos) can be analyzed using one or more imageprocessing techniques, as are known to those of ordinary skill in theart. In doing so, one or more indicators can be identified within thevisual capture, and such indicators can preferably be further utilizedto determine if/how one or more restrictions are to be adjusted at/inrelation to the mobile device 105, as will be described in greaterdetail below.

The following are exemplary and non-limiting illustrations of variousvisual captures that can be received, and indicators that can beidentified within the respective visual capture:

In one implementation, a visual capture can include an image of at leasta portion of a face of a user, and such a visual capture can beprocessed to identify one or more indicators that reflect a steady gazeof the user. It can be appreciated that while a vehicle is in motion, apassenger in a vehicle is more likely to be able to maintain an ongoingsteady gaze into a camera of a mobile device than a driver who willnecessarily divert his/her gaze in order to see the road while driving.

In another implementation, a visual capture can include an image of atleast a portion of a face of a user, and such a visual capture can beprocessed to identify an absence of a steering wheel in the visualcapture. It can be appreciated that a visual capture that contains thepresence of a steering wheel together with at least a portion of a faceof a user indicates that it is likely that the user is in closeproximity to the steering wheel, and is thus more likely to be a driverof the vehicle. Thus, in visual captures where the steering wheel hasbeen determined to be absent, it can be determine that the user of thedevice which captured such a visual capture is likely to be a passenger.

In another implementation, a visual capture can include an image of oneor more feet of a user, and such a visual capture can be processed toidentify a position of the one or more feet. That is, it can beappreciated that a visual capture of the feet of a driver is likely toinclude one or more pedals (e.g., gas, brake, and/or clutch), and/or thepositioning of the feet of the driver, either on or around such pedals.Conversely, the absence of such pedals and/or the foot positioning thatthey entails, indicates that the user of the device which captured theimage capture is likely to be a passenger.

In another implementation, a visual capture can include an image of atleast a portion of a body of a user, and such a visual capture can beprocessed to identify a presence of a fastened seatbelt in a passengerorientation, as depicted in FIG. 15B and as will be described in greaterdetail below with respect to step 1720.

In another implementation, a visual capture can include an image of aninterior of a vehicle, and such a visual capture can be processed toidentify at least two hands and a steering wheel, as will be describedin greater detail below with respect to step 1542.

By way of further illustration in another implementation, a videocapture that reflects the scenery outside of a vehicle can be processed,such as using image/video analysis, to determine the orientation of themobile device. In order to do so, indicators such as the position of thesky and/or horizon can be identified within the in the visual capture,such as using image processing methods and approaches known to those ofordinary skill in the art. It can be appreciated that various aspects ofthe visual capture will necessarily change based on the orientation ofdevice 105 and/or the relative location of the device within thevehicle. It can thus be appreciated that in doing so, the orientation ofmobile device 105 and/or the relative location of the device within avehicle can be determined, as will be described in greater detail below.

At step 1522, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or moreinputs, preferably from at least one of the sensors 145 of mobile device105, a vehicle data system 164, and/or one or more other mobile devices160, substantially in the manner described above with respect to step710. It should also be understood that various inputs can be receivedfrom multiple sources (e.g., various sensors, devices, etc.). Forexample, inputs from accelerometer 145A and/or gyroscope 145B can bereceived, such inputs corresponding to an orientation of mobile device105. By way of further example, one or more input(s) from one or moretactile sensor(s) 145N, such as the simultaneous depressing of one ormore buttons, and/or the simultaneous tactile interaction of multiplepoints and/or locations on a touchscreen display.

At step 1524, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 processes the one ormore inputs, such as those received at step 1522, to determine apresence of a passenger within a vehicle. By way of example, inputs canbe received from vehicle data system 164, such as those originating atvarious sensors deployed within a vehicle, such as weight/heat sensorsthat are positioned within one or more seats, and/or sensors that candetect whether one or more seatbelts are/are not fastened. Such inputscan be processed in order to determine a presence of, and/or thelikelihood of the presence of, one or more passengers within a vehicle.

At step 1526, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 processes the one ormore inputs with the visual capture and/or the indicators to determine arelationship between the inputs and the visual capture and/or theindicators. That is, it can be appreciated that the processing of inputsfrom one or more of sensors 145 (and/or from other sources) togetherwith the visual capture/indicators can further enhance the accuracy ofdeterminations made and/or actions taken, such as the determination ofthe orientation and/or location of device 105, as referenced above. Forexample, inputs from accelerometer 145A and/or gyroscope 145B can beprocessed together with the referenced visual capture/indicators inorder to determine an orientation of the device 105 and/or a relativelocation of the device with increased accuracy. That is, it can beappreciated that if the visual capture/indicators reflect sceneryoutside the vehicle, such visual capture/indicators can be processed todetermine the direction in which the mobile device 105 is traveling. Forinstance, if a stationary item (and/or an item moving at a speed slowerthan the vehicle within which the user is traveling) identified in thevisual capture moves from left to right over the course of the visualcapture (such as the progression from Frame 1 to Frame 3 as depicted inFIG. 19), it can be determined that such a visual capture was taken withthe mobile device 105 being oriented such that the visual capture istaken from the right side of the vehicle. Accordingly, it can bereasonably concluded that the user capturing such a visual capture isnot the driver of the vehicle (who would be seated on the left side ofthe vehicle). Similarly, a stationary item identified in the visualcapture moves from right to left over the course of the visual capture(such as the progression from Frame 1 a to Frame 3 a as depicted in FIG.19), it can be determined that such a visual capture was taken with themobile device 105 being oriented such that the visual capture is takenfrom the left side of the vehicle, and thus it cannot be determined withcertainty that the user is not the driver of the vehicle. It can be saidthat such determinations reflect a relationship between the inputs andthe visual capture/indicators.

By way of further illustration, in one implementation, a relationshipcan be determined wherein preferably while the vehicle is in motion, theuser presses the device against the vehicle's right-side window with thedevice oriented so that the Y axis of the device (as shown in FIGS.9A-9B and described in detail herein) is pointed in the forwarddirection that the car is traveling in, the device is oriented so thatthe positive part of the X-axis (as shown in FIGS. 9A-9B) is facing upand the rear-facing camera of the device is facing out (togetherreferred to as the “required orientation”, as shown in FIG.15C)—something that in most circumstances only a passenger can do (itcan also be appreciated that the “required orientation” can beconfigured to account for cameras in other positions on the mobiledevice, such as a camera on the front face of the device—wherein it canbe appreciated that the negative side of the X-axis is to be facing up).Indicators can be identified, such as by processing the one or morevisual captures originating from the camera of the device to determineif the movement of pixels or blocks of pixels or features of interest inone or more successive visual captures are consistent with the devicebeing on the right window (e.g., if pixels in successive frame aremoving from left-to-right as opposed to right-to-left if the device wereon the left window), as are known to those of ordinary skill in the art.The referenced visual capture and/or indicators can be processed withthe one or more inputs to determine a relationship therebetween.

At this juncture, it can be appreciated that while implementations suchas those where the processing of a visual capture/indicators to identifythe direction in which stationary objects (and/or objects moving at aspeed slower than the vehicle within which the user is traveling) moveover the course of several frames (that is, left to right or right toleft) can enable a determination with a certain degree of certainty asto whether the visual capture was taken from the right side of a movingvehicle (indicating that the visual capture was taken by a passenger) orthe left side of a moving vehicle (indicating that the visual capturewas not necessarily taken by a passenger), in certain situations furthervalidation can be advantageous. This is because, in certain scenarios, adriver, though seated on the left side of the moving vehicle, can stilltake a visual capture that shows stationary objects moving from left toright. Accordingly, it can be appreciated that analyzing additionalinputs and/or factors can be advantageous in order to further determinethat a driver is not actually skewing the determinations referencedabove.

By way of example, in certain implementations, one or more inputs (e.g.,inputs originating at an accelerometer, gyroscope, magnetometer, camera,etc.) can also be processed (such as in the manner described in detailherein) in order to determine a stability of mobile device 105. Itshould be understood that any number of inputs and/or combinations ofinputs can be processed in order to determine the stability of device105. It can be appreciated that the degree of stability of device 105can be indicative of whether a user of the mobile device is a driver ora passenger in that in a scenario where a driver points device 105towards the right-hand window of the vehicle, it is likely that themobile device 105 is supported only by the hand of the driver within theinterior of the vehicle (it should also be recognized that given thefact that the driver must remain on the extreme left-hand side of thevehicle in order to operate the vehicle whose controls are situated onthat side, it is exceedingly difficult, if not impossible, for thedriver to effectively operate the vehicle while also reaching across thewidth of the car to the right-hand window). Given this positioning, amobile device 105 operated by a driver of a vehicle is generally subjectto considerable instability, especially when the vehicle is moving. Apassenger, conversely, who can be seated on the right side of thevehicle, generally has the ability to hold and/or position his/hermobile device 105 against the window, wall panel, and/or door of thevehicle. Doing so provides an additional measure of stability which isgenerally unattainable by a driver, as discussed above. As such, it canbe appreciated that by determining the stability of mobile device 105,and additionally, by identifying a relationship between the one or moreinputs and the visual capture/indicators, the systems and methodsdisclosed herein can better identify and/or account for operation of thedevice by drivers and/or passengers.

As noted in the example above, any number of inputs (both individuallyas wells as when processed in combination) can be analyzed in order todetermine the stability of mobile device 105. By way of furtherillustration, the visual capture/indicators themselves can beanalyzed/processed in order to identify the degree of “shake” present,in a manner known to those of ordinary skill in the art. That is, it canbe appreciated that multiple indicators can be identified from a singlevisual capture. For example, it can be appreciated that if an amount ordegree of “shake” can be detected in a visual capture (in addition toother indicators that can be identified in the same visual capture, suchas those described in detail above). In determining such anamount/degree of shake, it can be further determined that mobile device105 is likely positioned in an unstable manner (such as by being held ina manner other than by being positioned against a window of thevehicle), and thus has a significant likelihood of being operated by adriver of the vehicle. Various other inputs, such as inputs from thegyroscope 145B and/or the accelerometer 145A can also beprocessed/analyzed to determine the stability of the mobile device 105.

By way of further illustration, in certain implementations, in additionto identifying one or more indicators within a visual capture, asdescribe in detail above, determinations (such as those that can becomputed based on the indicators, such as that the user of the device isa driver or passenger of the vehicle) can be further confirmed/verifiedby processing the visual capture(s)/indicator(s) with one or more otherinputs in order to determine a relationship between them. For example,it can be appreciated that a determination that the mobile device ispressed against the window (as opposed to held by the user just lookingout of the window), in the required orientation, can be computed basedon inputs originating at the accelerometer and/or gyroscope and/or othersensors. In doing so, any number of determinations can be computed, inpart in order to confirm that the device is being held in a mannerconsistent with being pressed against a window. For example, (i) if itcan be determined that the device moves/shakes relatively less than itwould if it were held in a hand that is not supported by a window and/ordoor; (ii) if the device vibrates consistently with being held against awindow; and/or (iii) if the visual capture(s) of the mobile device donot contain pixel blocks indicative of the device not being againstwindow (e.g., near-fixed pixels on the borders of the visual captureshowing the door or the roof or the window frame of the vehicle, etc.)in the preferred/required orientation that is consistent with a userpointing the rear-facing camera of the device out the window of avehicle (wherein the camera sees light, the camera sees moving pixels,and/or the inward facing light sensor shows an amount of lightconsistent with pointing inward in the required orientation, as is knownto those of ordinary skill in the art).

In certain implementations, the device being pressed against theright-side window of the vehicle in the required orientation (asdescribed above) can be verified by processing one or more inputs, suchas those originating at the accelerometer, by tracking the movement ofthe device immediately prior to its being pressed against a window. If,before determining/validating that the device is pressed against awindow in the required orientation, and/or after accounting for changesin the orientation of the device during such period of movement, thedevice moved to the right relative to the direction in which the vehicleis heading, then it can be determined that the device has moved to theright-side window. This determination can preferably be computed basedon inputs originating at the accelerometer, the gyroscope, the GPSand/or the magnetometer, as is known to those of ordinary skill in theart. It should be understood that such approaches can operateindependently and/or in conjunction with one or more of the variousimplementations and approaches described in detail herein.

In certain implementations, the in-vehicle role of a device user can bedetermined based on a processing of a visual capture from the device toidentify various objects, indicators, and/or patterns and determine thein-vehicle location and/or in-vehicle role of the user based on suchobjects, indicators, and/or patterns. For example, identifying a gaspedal in the rear-facing camera (or any other camera) on the device(e.g., within an image captured by such camera) is relatively likely toindicate a driver is operating such a device. By way of further example,identifying a seat belt going over a left shoulder of a user (e.g.,within an image captured by such camera) is relatively likely toindicate that a passenger is operating such a device (reverse for the UKand other left side of road driving countries). By way of furtherexample, identifying a window in the front facing camera(s) (e.g.,within an image captured by such camera) to the left of a user (asperceived by the camera(s)) is relatively likely to indicate that apassenger is operating such a device.

In certain implementations, one or more visual captures captured using afront-facing camera(s) (or other device camera(s)) of a device can beprocessed to determine the head/face angle (that is, the angle at whichthe head or face of the user is oriented, such as with respect to adevice/camera) and/or gaze angle (that is, the angle at which the eye(s)of the user are oriented, such as with respect to a device/camera, whichmay differ from the head/face angle) of the user, such as in relation tothe device and, based on such angles and/or based upon the variabilityof such angles over time, the in-vehicle role of the user of the devicecan be determined. For example, passengers are likely to exhibit certainhead and/or gaze angles in relation to a device and/or in relation to avehicle that drivers are relatively less likely to be able to. Inaddition, passengers are relatively likely to be able to maintaincertain head and/or gaze angles in relation to a mobile device and/or inrelation to a vehicle for longer lengths of time and/or with lessvariability than drivers can (because, for example, passengers are lesslikely to have to look at the road ahead).

FIG. 57 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 5710, one or more visual captures (e.g., digital images, videos,etc.) can be captured and/or received.

At 5720, the one or more visual captures (such as those received at5710) can be processed. In doing so, a head/face angle and/or an eyegaze angle can be determined (e.g., using one or more facial recognitionand/or image analysis techniques such as are known to those of ordinaryskill in the art). In certain implementations, such a head/face angleand/or an eye gaze angle can be determined in relation to a device(e.g., a smartphone or other mobile device, such as a device that wasused to capture the visual captures). Moreover, in certainimplementations the referenced visual captures can be processed todetermine whether the head angle and/or the eye gaze angle aremaintained with respect to the device (e.g., within a defined margin oferror) for at least a defined chronological interval (e.g., 10 seconds).Doing so can ensure that a driver cannot simply momentarily orienthis/her head/face or eyes at a certain angle (e.g., looking ‘down’towards a mobile device that is lying flat) and then change his/herhead/face/eye orientation.

Additionally, in certain implementations the referenced visual capturescan be processed to determine a head/face orientation angle in relationto a device and an eye gaze angle in relation to the head/faceorientation (reflecting, for example, whether the eye gaze angle of auser is or is not relatively consistent with the head/face orientationangle). Doing so can be advantageous in that it can enable theidentification of scenarios in which the head/face of a user is orientedat one angle but the eye gaze of the user is oriented at a differentangle—reflecting that the user is looking away (e.g., in an attempt toauthenticate him/herself as a passenger while looking away with theireyes and continuing to drive).

At 5730, the defined chronological interval (such as the interval withrespect to which the head/face and/or eye gaze angle is to bemaintained, such as at 5720) can be adjusted. In certainimplementations, such an interval can be adjusted based on a determinedspeed (e.g., the speed at which the device and/or the vehicle withinwhich it is present, can be determined to be traveling). By way ofillustration, as noted the described technique(s) can be configured toaccount for the speed of the vehicle (as can be obtained, for example,through GPS or an in-vehicle system). It can be advantageous to do sobecause the abilities of passengers and drivers may become more and moredifferent as the vehicle speed increases because the driver is likely toneed to dedicate greater attention to driving and thus is relativelyless likely to be able to hold the referenced gaze, over a period oftime. For example, if a device and/or vehicle is determined to betraveling below 40 miles per hour, the described technologies may beconfigured to instruct/require the user to maintain his/her head/faceand/or eye gaze angle(s) for a 10 second interval, while if the deviceand/or vehicle is determined to be traveling above 40 miles per hour,the described technologies may be configured to instruct/require theuser to maintain his/her head/face and/or eye gaze angle(s) for a 5second interval.

At 5740, an orientation angle of the device relative to the ground (orany other such surface) can be determined. In certain implementations,such an orientation angle can be required to be a substantially flatorientation (e.g., as depicted in FIG. 15G and described in detailherein).

At 5750, the head/face angle and/or the eye gaze angle (such as aredetermined at 5720) can be compared to the orientation angle of thedevice (such as is determined at 5740). In doing so, a relationshipbetween the head/face angle and/or the eye gaze angle and theorientation angle of the device can be determined.

At 5760, based on the head/face angle and/or the eye gaze angle (such asare determined at 5720) and/or the relationship between the head/faceangle and/or the eye gaze angle and the orientation angle of the device(such as is determined at 5750), a relative likelihood that a user ofthe device is a driver or a passenger can be computed.

Moreover, in certain implementations, a relative likelihood that a userof the device is a driver or a passenger can be computed based on (a)the head/face orientation angle in relation to the device (such as aredetermined at 5720), (b) the eye gaze angle in relation to the headorientation (such as is determined at 5720), and (c) an orientationangle of the device in relation to the ground (such as is determined at5740).

At 5770, an implementation of a restriction at a device can be modified.In certain implementations, such an implementation of a restriction canbe modified based on the relative likelihood that a user of the deviceis a driver or a passenger (e.g., as computed at 5760).

By way of further illustration, it can be appreciated that, in somecases, requiring certain orientations of a mobile device when performingcertain types of user authentication/verification techniques can serveas a surrogate for requiring that the user's face and/or eyes aredirected in a certain manner (e.g., so that the user cannotsimultaneously look at the road and successfully perform theauthentication/verification task). As such, by requiring that thedirection, orientation, and/or angle of the head/face of a user and/orthe eye gaze of the user to be within (or not within) one or morerange(s), such verification techniques and tasks can be even moredifficult to falsely authenticate.

For example, in order to determine the head/face angle of a userrelative to the ground/earth (and, in certain implementations, determinewhether it is within one or more range(s)), (i) the angle of the device(e.g., a smartphone) relative to the ground/earth can be determined(e.g., based on inputs originating from the accelerometer, compass,magnetometer, etc. of the device, such as in a manner known to those ofordinary skill in the art) and (ii) the angle of the head/face of theuser relative to the device can be determined (e.g., via image analysisof visual captures originating at the camera of the device). It shouldbe understood that, in certain implementations, there may be norequirements on (i) or (ii) individually, but on the combination of theresult of measurements (i) and (ii) together (note, in practice, incertain implementations there may be some practical requirements on (i)and (ii) individually, due to of factors like camera distortion).

Additionally, in order to determine the eye gaze angle of a userrelative to the ground/earth (and, in certain implementations, requireit to be within one or more range(s)), (i) the angle of the orientationof the device relative to the ground/earth can be determined (e.g.,based on inputs originating from the accelerometer, compass,magnetometer, etc. of the device, such as in a manner known to those ofordinary skill in the art), (ii) the angle of the head/face of the userrelative to the device can be determined (e.g., via image analysis ofvisual captures originating at the camera of the device), and (iii) theangle of the eye gaze of the user relative to his/her face can bedetermined. It should be understood that, in certain implementations,there may be no requirements on (i), (ii) or (iii) individually, thoughthere may be requirements on the combination of the results of (i) and(ii) and (iii) together (note, in practice, in certain implementationsthere may be some practical requirements on (i) and (ii) and (iii)individually because of factors like camera distortion).

While visual capture(s) can be used to enable passengers to activelyauthenticate themselves as such, such as is described herein, suchtechnologies can also be used to enable determination of an in-vehiclerole and/or in-vehicle location of the user of a device and/or thelikelihood thereof (e.g., in a passive manner). For example, a visualcapture (e.g., together with the orientation of the capturing devicerelative to the earth and/or relative to the vehicle) can be processedto match one or more pattern(s) that can be identified within the visualcapture to determine the location of a mobile device within the vehicleand/or the make/model of the vehicle that the device is present within.For example, using a database of physical properties of vehicleinteriors (which may include, for example, visual captures of suchinteriors, spacing information/specifications, object location,colorings, consistencies, ceiling, floor and side markings as provided,for example, by vehicle manufacturers and/or from crowdsourcing),captured images, videos, etc., including views of the vehicle fromdifferent device positions and/or orientations can be utilized, e.g., tocompare with various patterns (e.g., feature extractions) within avisual capture originating from a device (e.g., in addition to one ormore other techniques described herein or known to those of ordinaryskill in the art) to determine the in-vehicle location of the device.

In another implementation, various machine learning techniques can beemployed with respect to visual capture(s) using supervised (and/orunsupervised) training sets to better determine how to associate suchcaptures with in-vehicle locations and/or in-vehicle roles. Suchtechniques can be applied on a device by device basis, for a largerpopulation or for a combination of the two. For example, a device canlearn the ceiling of a car in which a person commutes in regularly and,for example, after collecting information over several trips, be able toidentify the in-vehicle location of a device in that car, and/or bymatching visual captures against a database of car ceilings/interiors.

It should be noted that such a database may also include views (actualor generated) of the interior of a vehicle in different lightingconditions (e.g., day vs. night) and/or the ability to compare actualvisual captures taken with simulations/projections of what suchinteriors are likely to look like under different lighting conditions(with or without ever actually rendering them).

In another embodiment, comparable technique(s) can be applied todetermine the mode of transportation and/or vehicle class that a deviceis present within (together with or without various others vehicle classdetermination techniques described herein or known to those of skill inthe art). For example, it can be appreciated that the patterns and/orphysical properties of interiors of different vehicles classes arelikely to perceptibly differ from one another. For example, a visualcapture originating from a device in a passenger car is likely to depictlower ceilings and a narrower interior and smaller windows as comparedto a comparable visual capture originating from a device present withina train or a bus. Here, too, in addition to determining the vehicleclass based upon such perceived distances within a visual capture, thevisual capture can be compared to a database of visual captures todetermine the class of vehicle that a device is in.

In certain implementations, a visual capture can be processed usingsimilar techniques to determine whether a user is traveling on publictransportation (e.g., bus or train), in which case, most/all surroundingdevices can be determined to be likely to be passenger devices (and thusneither the in-vehicle location nor in-vehicle role associated with sucha device necessarily need be determined) or non-public transportation(e.g., a car) in which case such determinations can be performed. (Itshould be noted that various techniques, such as those described herein,can be employed to restrict the devices of public transportationdrivers/operators to ensure that their devices would not enjoy such apublic transportation exemption).

In yet another embodiment, a visual capture can also be processed toimprove (e.g., based on accuracy, power, latency, etc.) the techniquesdescribed herein (or those of others) that attempt to determine whetheror not a device is present within a vehicle or a device (and/or itsuser) is present outside of a vehicle and/or engaged in another form ofactivity (with or without various other trip detection and/or activityrecognition techniques described herein or known to those of ordinaryskill in the art). For example, a visual capture originating from adevice present outside a vehicle can be differentiated/distinguishedfrom one taken inside a vehicle. A visual capture that can be processedto identify a pattern associated with a sidewalk (as captured from athen downward-facing camera) or open sky (as captured from a thenupward-facing camera) can be determined to be likely to be outside avehicle. By way of further example, identifying a pattern that shows abackground consisting of office ceiling tiles with a certain geometry(as captured from a then upward-facing camera) can indicate that thedevice is present indoors (i.e., not within a vehicle), while thepresence of window patterns, headrests, seatbelts, a steering wheel orgas pedals, etc. can be determined to be likely be in a vehicle.Different levels of light (adjusted, as needed for time of day,geography, weather conditions etc.), can also be utilized todifferentiate between devices inside vehicles and those outsidevehicles, and different levels of light between multiple cameras on thesame device can serve as a further indication of the same, such as isdescribed herein.

Moreover, in certain scenarios, multiple cameras can be used“stereophonically” to more accurately determine the device's in-vehiclelocation.

In a scenario in which one or more of the visual capture mechanisms isin use by another application, impeded, malfunctioning, etc., a defaultsetting can indicate the device as belonging to a driver (or apassenger), e.g., until capture of the visual capture is no longerimpeded. This can be done with or without given a warning notificationto the user.

It should be understood that various techniques described herein can beemployed device-side, server-side, and/or a combination of both.

It should also be noted that some of the techniques described herein mayinvolve identifying objects and/or features or properties within a stillimage and/or analyzing changes in the same or different aspects overmore than one image and, in some cases, in relation to other devicesensors (for example, changes in images as compared to changes perceivedin a position and/or orientation of a device, e.g., at the time thereferenced images are captured, such as in order to better measuredistance. For example, a device determined to have rotated two degreesand in which an object within various visual captures can be determinedto have moved by 200 pixels, can be used to further determine thedistance between the device and the object which, as previouslydescribed, can be different for different vehicle classes).

An accelerometer is used on many mobile devices (and/or in many mobileoperating systems) to determine the orientation in which the device'sscreen should be displayed (e.g., portrait, landscape, negative portraitor negative landscape). For example, if the accelerometer perceivessufficient gravity is falling on its y-axis, the screen displays inportrait (or negative portrait, depending on the sign of the y-axisaccelerometer value). If the accelerometer perceives sufficient gravityis falling on the x-axis, the screen displays in landscape (or negativelandscape, depending on the sign of the x-axis accelerometer value).However, such techniques are not necessarily effective in scenarios inwhich the accelerometer perceives relatively little gravity falling oneither the x-axis or the y-axis (e.g., the device is face up on a tableor being held upside down by someone using it while lying on her back,where substantially all the gravity falls on the device's z-axis). Manydevices (and/or operating systems) simply continue to use their lastscreen-display orientation until the accelerometer next perceives thatsufficient gravity is falling on the x-axis or the y-axis, whereupon thescreen-display orientation is rotated, as needed, and if different fromthe last screen-display orientation. As a result, when a user-deviceorientation changes (e.g., the user rotates the device, the user moveshis/her person) and the user wants the screen-display orientation of adevice whose device-earth orientation is substantially flat (e.g., mostof the gravity falls on the z-axis) to adjust appropriately (e.g., tobest-face the user), the user may need to tilt the device to change thedevice-earth orientation so that gravity is perceived on theaccelerometer's x-axis or y-axis, as the case may be, before thescreen-display orientation will rotate.

In order to improve such orientation changes, in one implementation, oneor more visual captures originating from the device can be processed toidentify/determine the orientation of the user with respect to thedevice and, based on such user-device orientation, the screen-displayorientation can be rotated, as and if necessary, to one that which isbest facing the user. For example, if the screen-display orientation isportrait, but the visual captures can be processed to determine that theuser's face (or head or eyes etc.) is more perpendicular to the devicethan it is parallel to it (e.g., the device's positive z-axis is pointedup relative to earth and the positive y-axis of the user's face ispointed north whereas the device's positive y-axis is pointed west (orat least west of north-west or west of south-west)), the screen displaycan be rotated to landscape (e.g., continuing this example, by 90degrees clockwise if it was rotated from the portrait screen-displayorientation). Or, for example, if the visual captures can be processedto determine that the user's face (or head or eyes) is largely parallelto the device but in the opposite direction (e.g., the device's negativez-axis is pointed up relative to earth and the positive y-axis of theuser's face is pointed north whereas the device's positive y-axis ispointed south (or at least south of south-west or south of south-east)),the screen display is rotated to negative portrait (i.e., to ascreen-display orientation that is 180 degrees from portrait).

In another implementation, the rotational motion of a device perceivedby its gyroscope can be accounted for in determining/measuring changesto the user-device orientation of a device that is in a substantiallyflat device-earth orientation. Based on the inputs from the gyroscope(e.g., its yaw readings, i.e., motion around the device's z-axis), thedevice's screen-display orientation can be rotated, as and if needed, tobe the one best-facing the user. For example, if the device's currentscreen-display orientation is portrait and the gyroscope's yaw readingsperceive that the device has undergone counter-clockwise movement aroundits z-axis (as observed by someone sitting on the positive z-axis) whosemagnitude and duration can be indicative of a turn of the device withrespect to its z-axis that is within some range (e.g., between 45degrees and 135 degrees), the device's screen-display orientation can berotated clockwise by 90 degrees to better align with the user's face.

In another implementation, the device's magnetometer/compass can beaccounted for in determining/measuring changes to the user-deviceorientation of a device that is in a substantially flat device-earthorientation. Based on the inputs from the magnetometer/compass (andchanges thereto), the device's screen-display orientation can berotated, as and if needed, to be the one best-facing the user. Forexample, in a scenario in which the device's current screen-displayorientation is portrait and based on inputs from the device'smagnetometer/compass it can be determined that the device orientationhas changed (e.g., with regard to magnetic north), for example, is hasrotated counter-clockwise around its z-axis (as observed by someonesitting on the positive z-axis) within some range (e.g., between 45degrees and 135 degrees), the device's screen-display orientation can berotated clockwise by 90 degrees to better align with the user's face.

It should be understood that the described implementations may berefined (e.g., to reduce power consumption, increase responsiveness),for example, by computing the user-device orientation or changes theretoupon determining that the device-earth orientation is substantially flatand/or upon determining that the screen is on and/or upon determiningthat there has been some motion on the device (as perceived, forexample, by its accelerometer, gyroscope and/or magnetometer/compass).

It should also be noted that the above techniques can be used together,either substantially simultaneously or serially (in either order) toimprove provide results.

It should also be noted that the described techniques can beadapted/configured to scenarios in which device screen-displayorientation may be less discrete (e.g., not limited to being at rightangles to the physical device).

In other implementations, the user can be required to perform one ormore simultaneous tactile interactions with the device. One or moreinputs can be processed in order to determine the number of instances ofsimultaneous tactile interaction. As referenced above, examples of suchtactile interactions include the depressing of one or more buttons,and/or the simultaneous tactile interaction of multiple points and/orlocations on a touchscreen display (commonly known as “multitouch”), asis known to those of ordinary skill in the art. It can be appreciatedthat in certain circumstances, in order to provide two (or more) suchsimultaneous tactile interactions, a single user must use both ofhis/her hands. In other implementations, in order to provide six (ormore) such simultaneous tactile interactions, a single user must useboth of his/her hands (assuming that a single hand is capable of at mostfive simultaneous tactile interactions).

By way of further illustration, FIG. 15A depicts an exemplary lockscreen, in accordance with at least one embodiment disclosed herein. Itshould be understood that while FIG. 15A is exemplary, it illustratesvarious aspects of the various approaches described in detail herein.For example, area 1560 depicts various blocks where numbers arepresented to the user (such as at random). The user is prompted to inputeach respective number (e.g., ‘3’) as the number is presented. Inrandomizing the numbers presented, the user is effectively required tobe attentive to the numbers being presented (as opposed to repeatedlyinputting the same user-defined lock code). Area 1565 (depicting animage of a fingerprint) corresponds to an area within which the usermust maintain constant contact throughout the authentication/unlockprocess with at least one finger (as described in detail herein). Indoing so, the user effectively must dedicate one hand to such constantcontact, thereby necessitating that the other unlock procedures (e.g.,the inputting of the numbers, as referenced above) be performed with theother hand of the user—thus effectively requiring the user of both ofthe hands of a user (and thereby creating a situation whereby such aprocedure is difficult, if not impossible, for a driver of a vehicle toachieve, especially while driving). Moreover, a timer 1570 is employed,requiring that the user perform the required authentication within aspecified time period (as described in detail herein). Moreover, an‘Emergency (all’ button 1575 enables the user to initiate emergencycommunications even without authenticating/unlocking the device, as isalso described herein.

As referenced above, in certain implementations, various of thereferenced approaches can be employed in combination and/or in parallel.Such arrangements entail the processing of multiple inputs, and/ordetermining one or more characteristics associated with the operationstate of mobile device 105, including but not limited to: an orientationof mobile device 105, the relative location of mobile device 105 withinthe vehicle, a relative movement of mobile device 105, a stability ofmobile device 105, and/or a number of simultaneous tactile interactionswith mobile device 105. More particularly, it can be appreciated thatthe implementation of multiple approaches can further increase theaccuracy of the collective determinations above that of a singledetermination, and ultimately ensuring that operation of mobile device105 by a driver of the vehicle is prevented and/or restricted, whileoperation by a passenger is permitted. Moreover, such inputs and/ordeterminations can be processed with other such determinations, visualcaptures, and or indicators, in order to identify relationshipstherebetween.

For example, a visual capture can be processed to identify one or moreindicators, and/or to determine the orientation of mobile device 105and/or the relative location of the device 105 within a vehicle (usingthe various image analysis techniques described in detail above). Thevisual capture/indicators and/or other inputs can be processed todetermine the stability of device 105, as described in detail above(thus further ensuring that the device is not being operated by adriver), while also determining a number of instances of simultaneoustactile interaction, as also described above. In particular, given thatmobile device 105 will generally need to be supported against avehicle's window in order to achieve both a) the proper orientation toobtain a suitable visual capture that confirms the orientation and/orlocation of mobile device 105, and b) the requisite stability (providedby lodging and/or supporting mobile device 105 against the window, wallpanel, and/or door of the vehicle), it can be appreciated that achievingeven this degree of orientation/stability requires substantial ongoingcontrol of at least one of a user's hands, as depicted in FIG. 20.Accordingly, it can be appreciated that a user must generally use most,if not all of, the fingers from one of their two hands to orient thedevice in such a way for any period of time. Thus, it can be furtherappreciated that practically any simultaneous tactile interactions withdevice 105 would be exceedingly difficult for a driver of the vehiclewho also needs at least one hand to steer. As such, requiring furtherinteraction with device 105 (e.g., a multi-finger swipe motion in orderto unlock or otherwise unrestrict the device), in combination with theabove referenced determination(s), can further confirm that such adevice is being operated only by a passenger.

In certain implementations, a device can be verified to be operated by apassenger by requiring the user to physically interact with the device(e.g., perform a multi-touch or swipe) while the user is pressing thedevice against a window of the vehicle in the required orientation in amanner that is likely to require the use of a second hand. It can beappreciated that a driver of a moving vehicle cannot easily (if at all)press a device against the window in the required orientation, hold itstably and interact with it. Let alone on the window on the oppositeside of the vehicle (s)he is driving.

Then, at step 1542, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105. It should be understood that in various scenarios, adjustingan implementation of a restriction can entail employing one or morerestrictions, modifying an implementation of one or more previouslyemployed restrictions, and/or removing one or more previously employedrestrictions. It should be further understood that the adjusting,employing of, modifying of, and/or removing of one or more restrictionsat/in relation to mobile device 105 is/are preferably effected based onone or more of the visual captures, indicators, relationship(s), andpresences, and/or determinations referenced above. For example, based onthe identification of one or more indicators (e.g., identifying thepresence/absence of a steering wheel in a visual capture, such as avisual capture of the face of the user while the device is held in ahorizontal orientation), one or more restrictions can be employed (e.g.,if a steering wheel is present in the visual capture, indicating thatthe user is likely a driver) and/or removed (e.g., if no steering wheelis present, indicating that the user is likely to be a passenger). Byway of further illustration, based on a determination that device 105 ison the left (driver's) side of the vehicle, a restriction can beemployed whereby the mobile device is no longer receptive to userinputs. By way of further example, based on a determination that device105 is facing out the right-hand window of the vehicle and is relativelystable, one or more previously employed restrictions of mobile device105 can be removed.

At this juncture, it should be understood that in variousimplementations, the accuracy and/or efficacy of certain of thereferenced inputs that are received and/or processed can be compromisedwhen the vehicle within which the mobile device is present is engaged ina turn (as determined, for example, based on inputs originating ataccelerometer 145A, gyroscope 145B, or the magnetometer 145E and/orcompass 145M, and as described in greater detail herein). This is inpart due to the various forces that are present in a turning vehiclethat are perceptible by various sensors such as an accelerometer (e.g.,through the centripetal force shown on its z-accelerometer) and/orgyroscope, which are not present when the vehicle is travelingsubstantially straight. Thus, in certain implementations, the varioussystems and methods described herein can be configured such that variousoperations, such as the receipt and/or processing of various inputs isprecluded (and/or the results of any processing or determination thatincorporated such results is discounted, discarded, and/or ignored) whenit can be determined that the referenced vehicle is engaged in a turn,such as in a manner described in detail herein.

It should be noted that in certain implementations it can be useful toloosen one or more restrictions (e.g., have them appearintermittently—either at random, at some fixed rate or dynamicallyaccording to certain events) after the device user (who has alreadypassenger authenticated) has and/or continues to interact with thedevice in a manner that further suggests that the user is the passengerby, for example, (a) using the keyboard at a good speed; (b) using thekeyboard with low and/or consistent inter-key time variations; (c) usingthe keyboard with a low level of typographical mistakes; (d) exhibitingdevice movement that is consistent with that of a passenger.

Moreover, in certain of the implementations described herein, as long asa vehicle occupant does not successfully authenticate as a passenger(and, optionally, even if the user does), it can be useful to allow theuser to operate and/or interact with the device via voice (e.g.,voice-to-text, voice-to-command, text-to-voice). This feature canoptionally be limited to devices that are in a cradle and/or are beingused in a hands-free manner.

Turning now to FIG. 16, a flow diagram is described showing a routine1600 that illustrates a broad aspect of a method for selectivelyrestricting operation of a mobile device 105 in accordance with at leastone embodiment disclosed herein.

At step 1610, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or morevisual captures, substantially in the manner described above withrespect to step 1510.

Then, at step 1620, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, processes atleast one of the visual captures (such as those received at step 1510)to identify one or more indicators within the visual capture,substantially in the manner described above with respect to step 1620.

At step 1622, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or moreinputs, such as a directional heading of mobile device 105 originatingat from GPS receiver 145C, substantially in the manner described abovewith respect to step 710.

At step 1623, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or moreinputs, such as a directional input 105 originating at from magnetometer145E and/or compass 145M, substantially in the manner described abovewith respect to step 710.

At step 1623A, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, computes one or moredeterminations, such as determinations reflecting orientation/positionof mobile device 105. By way of example, an input from the accelerometercan be received, preferably reflecting the X-axis position, and suchinput can be processed to confirm that the device is being held in therequired position with respect to the X-axis, such as in the mannerdescribed herein. Moreover, in certain implementations various of themethods described herein can be employed which determine the degree ofstability and/or the amount of “shake” present at the mobile device,based on which it can be determined whether the device is orientedagainst a door/window of a vehicle, such as in the manner describedabove with respect to FIG. 15.

Then, at step 1624, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, processesthe received inputs, including the directional heading and thedirectional input, and such input can be processed to confirm that thedevice is being held in the required orientation with respect to itsY-axis. That is, it can be appreciated that the directional headingoriginating at the GPS can be correlated with the directional input(s)from the magnetometer/compass in order determine the orientation of theY-axis of mobile device 105, as is known to those of ordinary skill inthe art.

At step 1626, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 further processes therelative orientation of a mobile device, such as of a device held in therequired orientation with respect to its x-axis (such as that determinedat step 1623A), with at least one of the visual capture (such as thatreceived at step 1610) and the one or more indicators (such as thoseidentified at step 1620) to determine the device's relative orientation.It should be understood that in certain implementations, in doing so, itcan be confirmed that the device is being held in the proper Y-axisorientation, i.e., if the device's positive Y-axis is pointed in thedirection of the vehicle. It certain implementations, it may be usefulto compare the device's Y-axis orientation as determined in step 1624with the device's Y-axis orientation determined in this step. Such wouldbe particularly useful in correcting a situation where the device wasincorrectly placed on the left window of the vehicle in the requiredX-axis orientation and with the rear facing camera point out (i.e., tothe left side), but which rear facing camera was incorrectly identifiedfrom the visual capture to be pointing to the right because a vehiclethat was moving faster than the vehicle in which the device is presentwas seen in the visual capture. It should be further understood that incertain implementations the required orientation of the rear-facingcamera of the device facing out against the window can be confirmed,and/or can be confirmed/determined to not be held facing out of thewindow based upon evidence in the visual capture originating at thedevice (e.g., by determining whether or that one or more interiorcomponents of the vehicle, e.g., the window pane, door, etc., arepresent in the visual capture) and can be confirmed to be facing outagainst the right window based upon the direction of movement of objectsas is described in detail herein. It should also be understood thatvarious additional confirmation approaches can be employed, such asvarious multi-touch and/or 2^(nd) camera methods, such as thosedescribed in detail herein. It can be further appreciated that computingsuch a correlation enables the further determination of the relativelocation of device 105 within the vehicle. In determining theorientation of device 105, such as a mobile device held in the requiredorientation referenced above (as determined based on the GPS and compassheadings), the perspective of the visual capture can be furtherappreciated, thereby enabling the determination of where the user is/isnot seated within the vehicle, and thus to what degree of likelihood theuser is/is not the driver and/or passenger of the vehicle.

The required orientation consists of three parts: (1) X-axis, (2)Y-axis, (3) pressed against (right) window, (forward-facing camerapointing out).

Accordingly, it should be understood that the operations described withrespect to steps 1623A-1626 pertain to various aspects of the “requiredorientation” as described herein. It should be understood that the“required orientation” preferably consists of/incorporates threeparts/aspects/determinations: (1) X-axis, (2) Y-axis, and (3) that thedevice is pressed against the window of a vehicle, preferably with therear-facing camera of the device facing out.

Accordingly, it should be understood that inputs originating at theX-axis accelerometer can be processed to confirm that the device isbeing held in the required X-axis orientation, i.e., landscapeorientation, as described herein. Moreover, inputs originating at thecamera (i.e., visual captures) can be processed, wherein generallystationary/slower moving objects should move from left to right, and/orGPS heading can be processed against the magnetometer direction toconfirm the required Y-axis orientation, i.e., positive Y-axis indirection of vehicle's movement. It can be appreciated that doing soalso establishes that the camera (i.e., the rear facing camera) ispointing to the right. Moreover, the degree of “shake”perceived/determined at the device (as it can be appreciated that adevice shakes relatively less when held against a window than when heldby hand) and/or aspects determined based on the visual capture (beingthat a device held against window will not show interior components ofvehicle) can be processed to confirm that the device is pressed againstwindow. Based on the combined processing of these elements, it can bedetermined that the device is oriented at the right-hand side window ofthe vehicle, as described herein.

By way of further illustrations, it should be understood that one ormore of the above referenced implementations (e.g., the visual captureprocessing, the stability determination, etc.) can be further enhanced(or, alternatively, the present implementation can be employedindependently, without connection to any other of the implementationsdescribed herein) by verifying that the device is pressed against theright window in the required orientation by using the GPS sensor and themagnetometer and/or compass to verify that the orientation of the mobiledevice is consistent with being pressed against the right window of avehicle in the correct orientation (as described in detail above). Forexample, it can be appreciated that in a scenario where a device ispressed against the left-hand side window of a vehicle window in anattempt to fraudulently authenticate the device in the manner describedherein, such a device would still provide a GPS heading that isdiscernibly different than a device comparably positioned against theright-hand window of the vehicle Accordingly, even in a scenario whereother of the above-referenced implementations do not accuratelydetermine the identity of the use of the device (as a driver orpassenger), the present approach can provide an accuratedetermination/authentication of the identity of the user of the deviceas a driver or passenger.

Then, at step 1642, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, and/orremoves one or more previously employed restrictions) based on thecorrelation, substantially in the manner described in detail above withrespect to step 1542.

Turning now to FIG. 17, a flow diagram is described showing a routine1700 that illustrates a broad aspect of a method for authenticating anin vehicle role of a user of a mobile device and/or modifying arestriction of a mobile device 105 in accordance with at least oneembodiment disclosed herein.

It can be appreciated that in order for a user to utilize thefunctionality of the integrated camera 145F of mobile device 105, such auser must grasp and/or come into contact with mobile device 105 with atleast one hand. As such, it can be further appreciated that a visualcapture taken by camera 145F that depicts two hands of a driver can bedetermined to be likely to have been taken by a user other than thedriver of a vehicle, as will be described in greater detail below.

At step 1705, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs one or morerestrictions at mobile device 105 and/or in relation to mobile device105, substantially in the manner described above with respect to step1505. By way of illustration, in certain implementations suchrestrictions can configure the mobile device 105 to operate only inlandscape mode (that is, depicting the content/user interface shown onthe display of the mobile device be depicted only in a landscape, i.e.,lengthwise fashion) and/or in landscape orientation (that is, requiringthat the X-axis of the mobile device must detect gravity, as is known tothose of ordinary skill in the art—e.g., when held lengthwise—anorientation that generally requires two hands to effectively navigateand/or provide inputs to), as is known to those of ordinary skill in theart. By way of further illustration, in certain implementations suchrestrictions can configure mobile device 105 to receive various inputsonly when the mobile device is oriented at a defined orientation and/orwithin a defined range of orientations (as can be determined using theaccelerometer and/or gyroscope of the device). It should also be notedthat in certain implementations, the various restrictions employed at/inrelation to the mobile device 105 do not preclude partial and/or fulloperation of the device using voice commands, as is known to those ofordinary skill in the art. Moreover, in certain implementations, therestrictions do not preclude operation of the device for emergencypurposes, such as to call or text ‘911’; as is also known to those ofordinary skill in the art.

It should be noted that in scenarios where a device is oriented nearlyflat (as if it were on a table) it can be difficult to determine whetherthe device is being held in portrait or landscape orientation, i.e.,whether the Y-axis of the device is pointed towards/away from the user(i.e., portrait orientation) or whether it is perpendicular to the user(i.e., landscape orientation) because the X and Y accelerometers, whichare generally used to determine such, have zero readings in thisorientation.

The portrait vs. landscape orientation of such devices can nonethelessbe determined in cases where the device is held/oriented in such “flaton a table” or nearly “flat on a table” positions based on observationsas to how the values associated with the accelerometer and/or gyroscopesof a device change over time and how the “flatness” of the devicefluctuates over time (as users generally cannot hold the deviceperfectly still). For example, a device that is determined to be nearlyflat and in portrait orientation (i.e., with its Y-axis pointed at theuser) will tend to have greater pitch than roll, whereas were the samedevice positioned in landscape orientation (i.e., with its X-axispointed at the user), it would tend to have greater roll than pitch. Assuch, devices that are held flat and that exhibit greater pitch thanroll can be determined to be in portrait orientation and, based on sucha determination, can be configured such that the user interfacepresented on their screens is also in portrait mode, whereas devicesthat exhibit greater roll than pitch can be determined to be inlandscape orientation and, based on such a determination, can beconfigured such that the user interface presented on their screens isalso in landscape mode, for example.

At step 1707, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, prompts a user ofthe mobile device 105 to initiate and/or provide one or more firstinputs at mobile device 105, substantially in the manner described abovewith respect to step 707. At this juncture, it should be noted that incertain implementations, such prompting includes the presentation,display and/or projection of prompts to the user in an obfuscated and/orobscured manner. That is, such prompts are preferably presented,displayed, and/or projected in one or more ways that require increasedconcentration and/or attention in order for a user to properly observeand comprehend/appreciate the prompting. Such obscuring/obfuscating ofthe various prompts/prompting serves to convey the information containedin the prompting (e.g., a word or string that the user must type) insuch a way that is relatively more difficult for a driver toappreciate/understand (given that the driver is likely to be distractedby and/or concentrating on various ongoing driving-related tasks) thanfor a passenger to appreciate/understand (given that the passenger isless likely to be so distracted/concentrated).

By way of illustration, in certain implementations, such as those inwhich at least some portion of the referenced prompting is conveyed tothe user visually (e.g., through the screen of the device), it can beuseful to have some or all of such information presented, displayed,and/or projected in a manner that makes it more difficult for someonethat is less able to pay close attention to the existence and/or contentof such visual information that is required to successfully complete therequired action(s), thereby increasing the difficulty for a user who isdriving to successfully complete the requested stimulus/input. Forexample, such visual information can appear for only a short period oftime and/or a non-constant time interval (including intervals of timethat contain random components) so that a driver of a moving vehicle,who is relatively less able to focus on such visual information, is morelikely to miss and/or not see it and/or not process such promptinginformation (or at least not comprehend/understand it as quickly as apassenger would, on average); thereby further preventing a driver of adevice from successfully unlocking such a device (and/or fraudulentlyauthenticating such a device as if the user were a passenger). Moreover,in other implementations, such prompting information can be displayed ina different manner (e.g., in a different location, orientation, color,font and/or shape), consistently and/or periodically. In doing so, itcan be appreciated that the ongoing changing of the manner or manners inwhich such prompts are presented, displayed, and/or projected introducesgreater unpredictability for the user viewing/expecting the prompting,thereby increasing the difficulty to the driver inanticipating/appreciating the prompting, as described.

At step 1710, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives at least afirst input. Such inputs can include, but are not limited to:alphanumeric inputs provided in response to a prompt (such as a CAPTCHAprompt, as is known to those of ordinary skill in the art), inputsprovided during the course of an interactive game, inputs provided in alock screen, inputs provided during the course of an interactive puzzle,one or more tactile gestures (such as one or more swipe gestures)provided at a tactile sensor such as a touchscreen of the mobile device105, one or more visual capture(s) and/or one or more inputs from one ormore of an accelerometer a gyroscope, a GPS receiver, a microphone, amagnetometer, a camera, a light sensor, a temperature sensor, analtitude sensor, a pressure sensor, a proximity sensor, a near-fieldcommunication (NFC) device, a compass, user interface, device buttons, acommunications interface, and a vehicle data system.

Then, at step 1720, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, processesthe one or more first inputs (such as those received at step 1710) tocompute a first determination, the first determination reflecting atleast one in-vehicle role indicator which relates to the in-vehicle roleof the user of the device as being either a driver or a passenger. Thisdetermination, reflecting an in-vehicle role of the user as adriver/passenger, preferably reflects an indication, such as one presentin a particular interaction with the mobile device 105, that the user ofmobile device 105 is/is not reflecting behavior that conforms with thatwhich can be determined to be associated with drivers and/or passengers.As will be illustrated in greater detail below, it should be understoodthat certain in-vehicle role indicators can enable determinationsregarding the role of a first user based on inputs such as visualcaptures that reflect aspects of another user (for example, if a firstuser takes a picture of a second user who is driving a car, it can bedetermined, based on an identification of the second user as a driver,that the first user is not a driver, and thus is a passenger), whileother in-vehicle role indicators can enable determinations based oninputs such as visual captures that reflect aspects of the userhim/herself.

By way of example, in one arrangement a visual capture (e.g., a digitalimage or video) can be processed, such as using image recognitiontechniques known to those of ordinary skill in the art, to identify,within the visual capture, two hands grasping a steering wheel. It canbe appreciated that a user grasping the steering wheel of a vehicle canbe determined to be likely to be the driver of the vehicle. However,based on the identification of two hands on the steering wheel, it canbe further determined that only a passenger in the vehicle is likely tobe capable of capturing such a picture using mobile device 105. (Itshould be understood that in certain implementations, further advancedimage processing techniques can be employed, whereby the two handsidentified on the steering wheel can be analyzed to determine that thetwo hands are substantially similar, and thus are likely to belong tothe driver—as opposed to the driver placing one hand on the wheel, andthe passenger placing another or the angle of the visual capture can beprocessed/analyzed to determine that the device is not likely to havebeen in a cradle or to require that the second camera of the device, ifavailable, also record a visual capture which can be processed to makesure there are no signs therein indicating that the driver performed thevisual capture, such as in the manner described herein.) Thus, it can beappreciated that in such implementations, while the visual captureitself depicts the hands of a driver, based on such a visual capture oneor more determinations can be computed regarding the likelihood that theidentity of the user that captured the picture (that is, the user of themobile device 105) is a passenger.

By way of further example, in another implementation a visual capturecan be received and processed, such as by using image recognitiontechniques known to those of ordinary skill in the art, to identify,within the visual capture, the positioning and/or orientation of a seatbelt in relation to a user. For instance, if the visual capture depictsa seatbelt as stretching from the right shoulder of a user to the leftthigh of a user, it can be reasonably determined that the pictured useris a passenger and not a driver.

By way of further example, in another implementation a user mayauthenticate himself as a passenger by facilitating the capture/receiptof a visual capture by the mobile device (e.g., from one or more of thedevice's cameras, such as a front-facing camera) that can be determined(e.g., via one or more image processing techniques) to include thefollowing elements: (i) a seat belt starting from the area of the user'sright shoulder (or left shoulder for certain countries like the U.K.which drive on the left side of the road), (ii) the user's face, and/or(iii) the window to the user's right. Such a visual capture can beanalyzed to determine whether or not it such elements can be determinedto be preset therein, such as by using image processing techniques knowto those of ordinary skill in the art.

By way of further example, such a technique may also be implemented in arelatively ‘passive’ manner, such as to make the same or similardeterminations based on visual capture(s) that are captured/received inthe same or similar manners, even without any direct assistance, input,or activity on the part of the user (e.g., by performing such analysisperiodically and/or continuously on visual captures that arecaptured/perceived by a camera of the device).

Moreover, in certain implementations, in an effort to prevent potential“spoofing” (that is, fraudulent authentication/verification) by driversin which a driver might place a strip of material (e.g., affixed to hershirt) in a manner appropriate to authenticate as a passenger, based ona determination that a sound or tone that corresponds to anotification/indication (e.g., by the vehicle) that an occupant's seatbelt is not fastened while the vehicle is in motion is (or was) audible(e.g., as perceived by one or more of the device's microphones), theauthentication attempt can be terminated/ended in failure.

By way of further example, in certain embodiments, an in-vehicle role ofa user can be determined if, the user can configure the device tocapture a visual capture that can be processed to identify one or moreindicators which, implicitly or explicitly indicate that there is apassenger in the car. (It should be understood that such visualcapture(s) are preferably captured while the vehicle is in motion, asdescribed in detail above). For example, as referenced above, if theuser is able to take a visual capture of two hands on the steeringwheel, the user of such device can be determined to be a passenger (as adriver generally cannot both take a visual capture with the device andhold the steering wheel with two hands). By way of further example, ifthe user of the device takes a visual capture within which a seatbeltgoing from the right shoulder of the user to left thigh of the user canbe identified, the user of such a device can be determined to be apassenger (being that a visual capture that a driver would take ofhim/herself is likely to show a seatbelt going in the oppositedirection).

At this juncture, it should be noted that in certain implementations,various other inputs, including but not limited to visual capture(s),can be received and/or processed in order to determine an in-vehiclerole of a user of mobile device 105. For example, mobile device 105 canbe positioned (such as in a dock) such that visual capture(s) receivedby/at the mobile device relate to a user's gaze (captured using afront-facing and/or rear-facing camera of the mobile device, dependingon the orientation of the device, as can be appreciated by those ofordinary skill in the art). That is, the visual capture can beanalyzed/processed using image processing techniques known to those ofordinary skill in the art, to identify the movements of a user's eyes,preferably while the vehicle is in motion (as can be determined based onvarious inputs, such as the accelerometer 145A). By way of illustration,if analysis of the visual capture reveals that the gaze of the eyes ofthe user of the device constantly and quickly returns to the directionof the windshield, it can be determined that the user is likely thedriver (as such a pattern would be typical of a driver who needs tomaintain ongoing view of the road while driving).

By way of further illustration, in certain implementations, anin-vehicle role of a user of a mobile device can be determined to be apassenger if, while the vehicle is in motion, the user is able toconfigure the device to take a visual capture based upon which it can beidentified (such as through image processing techniques as referencedherein) that the user is able to look (i.e., focus his head and/orgaze/vision) in a manner that only a passenger can and/or a drivercannot. For example, if it can be determined, such as through thereferenced image processing analysis of the visual capture, that theuser of the device is capable of maintaining a substantiallyconsistent/continuous look/gaze in the direction of the device for adefined period or certain periods of time, the in-vehicle role of such auser can be determined to be a passenger.

At step 1725, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, validates one ormore determinations, such as the determinations computed at step 1720.That is, as referenced herein, it can be appreciated that under certaincircumstances and/or scenarios, any number of determination approachescan be susceptible to error and/or fraud. As such, it can beadvantageous to further validate such determinations, thereby increasingthe respective accuracy of each determination. The particulars of suchvalidations will be described with reference to FIG. 17A.

Turning now to FIG. 17A, at step 1726, processor 110 executing one ormore of software modules 130, including, preferably, restriction module171, receives one or more second inputs, substantially in the mannerdescribed in detail above with respect to step 1710. In certainimplementations, such second inputs are preferably different inputs fromthose received at step 1710 (by virtue of the second inputs originatingfrom a different sensor and/or source, or by virtue of the second inputsbeing a separate input instance from the first input). By way ofexample, such second inputs can be received from the accelerometerand/or the gyroscope of mobile device 105.

At step 1727, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes the secondinputs (such as those received at step 1726) to compute a seconddetermination, substantially in the manner described in detail abovewith respect to step 1720. In certain implementations (even those wherethe second input originates from the same source as the first input) thesecond determination is preferably independent of the firstdetermination, such as the determination computed at step 1720. By wayof illustration, the second determination (computed based upon inputsreceived from the gyroscope and/or accelerometer of the device) canreflect an orientation of the device, such as an orientation of thedevice with respect to the ground/earth. By way of further illustration,the second determination (computed based upon inputs received from thegyroscope, accelerometer, and/or GPS/magnetometer of the device) canreflect an orientation of the device, such as an orientation of thedevice with respect to the vehicle within which the device is present,as described herein. By way of further illustration, the seconddetermination (computed based upon inputs received from the gyroscopeand/or accelerometer of the device) can reflect a pattern or trend thatreflects the manner in which the vehicle within which the device ispresent is moving (e.g., reflecting acceleration, deceleration,stability, etc.). By way of further illustration, in an implementationwhere it can be determined that the focus of the user's gaze towards thewindshield (as identified based on the processing of a visual capture,as described herein) tends to increase during periods of acceleration,fast speed, and/or other movements, this correlation can indicate thatthe user is a driver (as a driver is likely to pay additional attentionto the road as such driving events occur). (It should be noted thatmobile devices 105 having dual cameras—that is, cameras on both theiranterior and posterior sides, as are well known to those of ordinaryskill in the art, are well suited for the referenced determinations, asthey enable visual captures of both a user's gaze as well as the sceneryoutside the vehicle's windshield.)

At step 1728, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, determines avalidity of at least one of the first determination and/or the seconddetermination. In certain implementations, the validity is determined bycomparing the determinations and/or identifying correlations,relationships, patterns, correspondences, and/or discrepancies betweenthem. By way of further illustration, in certain implementations, if itcan be determined, such as through the referenced image processinganalysis of the visual capture, that the user of the device is capableof maintaining a substantially consistent/continuous look/gaze in thedirection of the device for a defined period or certain periods of time,while the device is held in a certain manner, such as at a particularorientation (as can be determined, for example, using theaccelerometer/gyroscope of the mobile device 105), the in-vehicle roleof such a user can be determined to be a passenger. It can beappreciated that by requiring that the user maintain his/her look/gazetowards the mobile device while the device is positioned at a particularorientation, such as an orientation and/or a range of orientations thatentails the device being positioned substantially horizontally, a usercan effectively be prevented from simultaneously looking at the deviceand also looking at the road ahead. For example, in a scenario where theangle of the device (as can be measured/determined, for example, usinginputs originating from the accelerometer and/or gyroscope of thedevice) is oriented more than a defined threshold amount/number ofdegrees (e.g., 10, 20, or 30 degrees)(upward/downward/rightward/leftward or some combination thereof) fromthe typical line of sight of the driver in a moving car, such as isdepicted, for example, in FIG. 17B, the in-vehicle role of a user who iscapable of maintaining a substantially consistent look/gaze toward themobile device (as determined through an analysis of the visual capture,as described above) while the device maintains such an orientation canbe determined to be a passenger (since it is highly unlikely that adriver of a moving vehicle is capable of maintaining such a gaze towardsthe mobile device while the mobile device is so oriented, while alsoeffectively driving a moving vehicle). It should be understood that thereferenced examples are merely exemplary, and that numerous otherimplementations are also contemplated, utilizing other inputs, as can beappreciated by those of ordinary skill in the art.

At this juncture, it should be noted that in certain implementations,the various visual capture(s) referenced herein can be processed againstone or more databases, such as databases that maintainimages/photographs, and such processing can be further utilized indetermining the in-vehicle role of a user of a mobile device. Forexample, it can be appreciated that many regulatory agencies (such as adepartment of motor vehicles) maintain databases of images of alllicensed drivers within a particular jurisdiction. Moreover, it can beappreciated that certain mobile device users, such as children, thevisually impaired, and/or the elderly, can frequently travel in vehiclesdespite the fact that these individuals do not drive, by virtue of thefact that they are not licensed to drive. Thus, in certainimplementations, the visual capture of the face of a user can beprocessed against such a database that maintains photographs of licenseddrivers. Using image recognition techniques known to those of ordinaryskill in the art, if one (or more) photographs from the licensed driverdatabase are identified as substantially similar to the image capture ofthe face of the user of the mobile device, it can be determined that theuser is more likely to be a driver (by virtue of the fact that such auser is known to at least possibly be a licensed driver, and thus canhave a propensity to drive). Conversely, if no photographs from such adatabase are identified as being substantially similar y to the imagecapture of the face of the user of the mobile device, it can bedetermined that the user is more likely to be a passenger (by virtue ofthe fact that such a user may not even possess a license to drive).

By way of further illustration, the above referenced approach(identifying an in-vehicle role of a user based on the degree to whichthe user can focus his/her look or gaze) can be further implemented inconjunction with one or more of the other approaches described herein.For example, in a scenario where mobile device 105 is equipped with twocameras (e.g., a forward-facing camera which faces the user whenoperating the phone, and a rear-facing camera which faces away from theuser like most traditional cameras), by processing visual captures froma first camera facing the user and visual captures from a second camerafacing away from the user (and preferably outside a vehicle window).Based on the processing of such visual captures, a determination thatthe device is on the right-side of the vehicle can be computed (asdescribed in detail above), and/or a determination that the user is ableto maintain a prolonged gaze towards the device can be computed (as alsodescribed in detail above). In such a scenario, it can be furtherdetermined that the in-vehicle role of such a user of the device is nota driver, and one or more restrictions of the device can be adjustedaccordingly.

Then, at step 1742, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, and/orremoves one or more previously employed restrictions) based on thedetermination and/or the validation, substantially in the mannerdescribed in detail above with respect to step 1642.

In certain implementations, in scenarios in which visual captures (e.g.,those described/referenced herein, such as for passenger authentication,etc.), are performed under low light conditions (e.g., night, rain,etc.), such as can be detected/determined based on input(s) originatingfrom one or more sensors of a device and/or other data sources (e.g.,light sensor, cameras, time/date/location, weather report, etc.),light/illumination originating from the device (e.g., screen, cameraflashes) can be used to improve the lighting conditions as needed (e.g.,illumination level, illumination direction, etc.), such as in order toimprove the quality of such visual captures such that they can beprocessed more effectively, accurately, efficiently, etc.

In certain implementations, inputs (e.g., visual captures) originatingfrom one or more front facing cameras on the device can be used todetermine the in-vehicle role of the user (and the set of restrictionsapplied to the device based upon the in-vehicle role) by detecting (ornot detecting) the presence and/or the characteristics (e.g., distance,size, orientation, angle, shape, color, slope, right/left, direction,in-image location, transparency, cleanliness) of one of more objects inthe input. For example, (a) a user's (or other person's) face/head; (b)the direction (and use) of a seat belt (i.e., over right shoulder orover left shoulder); (c) the presence and location of windows around auser; (d) the direction in which objects in a window around the user aremoving (e.g., right-to-left, left-to-right); and (e) the amount of lighton the right side and left sides of a user's face (relative to time ofday, direction of travel, location, etc.). In certain implementations avalue or measure of one or more of the characteristics (e.g., size,orientation, color, shape) of one or more of the one or more objectswhen captured by the one or more front facing camera on a device locatedin different positions in the vehicle (e.g., the positions associatedwith a driver, front right passenger, rear right passenger, rear middlepassenger, rear left passenger) can be determined or otherwise projectedor defined. The value/measure of one or more of the actualcharacteristics of one or more of the one or more objects in the visualcapture can be compared to the known values for different vehicleoccupants, based upon which the in-vehicle role of the user can bedetermined and a set of restrictions can be applied to the device basedupon the in-vehicle role.

In certain implementations, inputs from one or more rear-facing camerasof the device can be used to determine the in-vehicle role of the user(and the set of restrictions applied to the device based upon thein-vehicle role) by detecting (or not detecting) the presence and thecharacteristics (e.g., distance, size, orientation, angle, shape, color,slope, right/left, direction, in-image location, transparency,cleanliness) of one of more objects that are present in the input (ornot) and/or have different physical characteristics when seen by thecamera on a device located in different positions in the vehicle. Forexample (a) a steering wheel; (b) a vehicle dashboard; (c) the backs ofheads and/or head rests; (d) front hood; (e) the location of a hoodornament; (f) one or more windshield wipers or patterns on thewindshield made by the windshield wipers; (g) a rear-view mirror; (h)one or more sides of the windshield frame or the (resting) windshieldwipers; (i) a side mirror; (j) a user's (or other person's) face/head.

In certain implementations the approximate value of one or more of thecharacteristics (e.g., size, orientation, color, shape) of one or moreof the one or more objects when captured by the one or more rear facingcameras on a device located in different positions in the vehicle (e.g.,the positions associated with a driver, front right passenger, rearright passenger, rear middle passenger, rear left passenger) can bedetermined or otherwise projected or defined. The actual value of one ormore of the characteristics of one or more of the one or more objects inthe visual capture can be measured and compared to the known values fordifferent vehicle occupants, based upon which the in-vehicle role of theuser can be determined and a set of restrictions can be applied to thedevice based upon the in-vehicle role.

In certain implementations the visual capture tasks described herein canbe made more difficult (e.g., to discourage drivers) by introducingadditional requirements in order to perform the task (e.g., a buttonthat the user must tap in order to successfully perform the visualcapture (which is placed on the display of a device that a driver cannotsee because she needs to perform a capture with a rear camera), is in anrandom and changing location on the display).

In certain implementations, the inputs described herein as originatingfrom one or more front-facing cameras could also originate from one ormore rear-facing cameras and/or the inputs descried above as originatingfrom one or more rear-facing cameras could also originate from one ormore front-facing cameras. Additionally, the inputs could also come fromone or more cameras located in other positions on or in relation to thedevice.

In certain implementations, one or more of the front-camera classifiersand one or more of the rear-camera classifiers described herein can beused to make the in-vehicle role determination. The visual captures usedto make such determination may be performed simultaneously (i.e., frontand rear cameras capturing at the same time), interwoven (i.e., frontand rear captures taken in turn, e.g., one front frame, one rear frame,second front frame, second rear frame) or consecutively (i.e., frontcapture followed by rear capture, or vice versa).

In certain implementations, the user may be required to position thedevice in a particular way for the in-vehicle role to be determined(e.g., at a certain distance to her face, at a certain orientationrelative to earth (e.g. landscape, portrait), at a certain orientationrelative to the vehicle's direction of movement).

In certain implementations, the device orientation required may be basedupon the type of device (e.g., camera position). For example, when thedevice is a Nexus 5 where the camera is to the left of center (when thedevice is held in portrait), the user must hold the device in rightlandscape mode (so that the camera is higher than in left landscapemode), whereas on a device whose camera is right of center the user mustfold the device in the left landscape position. Unrelated to theheterogeneity of camera positioning across devices, different positionsmay be required under different conditions (e.g., time of day, day oryear, lighting).

In certain implementations, the above can happen actively (e.g., theuser who is a passenger initiates the process to release driver mode) orpassively.

For example, a user may be prompted to position a device in portraitmode (e.g., as perceived by the accelerometer) at a distance of 30 cm-40cm away from her face (e.g., both the presence of a face and thedevice's distance from face as perceived by the front-facing camera),and pointing towards the rear view mirror (e.g., as perceived by therear-facing camera), as shown in FIG. 86A. Visual captures can then becaptured or otherwise acquired using both the front and rear-facingcameras of the device, such as is described herein. The in-vehicle roleof the user can then be determined based upon (a) the angle of the rearview mirror in the rear-facing camera's visual capture (such as is shownin FIG. 86B). For example, in the scenario depicted in FIG. 87A (inwhich both a driver and passenger are performing substantially the sameauthentication task from their respective positions within the vehicle),it can be appreciated that the plane of the mirror is likely to be moreparallel to the plane of a driver's face (as reflected in FIG. 87B,showing the visual capture of the rearview mirror as captured by therear-facing camera of the device being operated by a driver, and FIG.87C, showing the corresponding visual capture of the user as captured bythe front-facing camera of the device being operated by a driver) andless parallel to the plane of a front-right passenger's face (asreflected in FIG. 87D, showing the visual capture of the rearview mirroras captured by the rear-facing camera of the device being operated by apassenger, and FIG. 87E, showing the corresponding visual capture of theuser as captured by the front-facing camera of the device being operatedby a passenger). By way of further example, in the scenario depicted inFIG. 88A (in which both a driver and passenger are performingsubstantially the same authentication task from their respectivepositions within the vehicle), it can be appreciated that the size ofthe rear view mirror and/or the size of the rear view mirror relative tothe face, e.g., the size of the rear view mirror and the ratio of therear size mirror size relative to the face size will be much smaller forrear-seat occupants (as reflected in FIG. 88D, showing the visualcapture of the rearview mirror as captured by the rear-facing camera ofthe device being operated by a passenger, and FIG. 88E, showing thecorresponding visual capture of the user as captured by the front-facingcamera of the device being operated by a passenger) than for front seatoccupants (as reflected in FIG. 88B, showing the visual capture of therearview mirror as captured by the rear-facing camera of the devicebeing operated by a driver, and FIG. 88C, showing the correspondingvisual capture of the user as captured by the front-facing camera of thedevice being operated by a driver). By way of further example, thedirection of the user's seat belt can be determined based on the visualcapture originating from the front-facing camera (such as is shown inFIG. 86C) e.g., identifying a seat belt over a user's right shoulder canindicate that the user is more likely to be a passenger, while a seatbelt over left shoulder can indicate that the user is more likely to bea passenger, as shown in FIGS. 87C and 87E. By way of further example,an identification of the windows around the user can also be anindicator of the user's role, e.g., a window on user's right canindicate that the user is more likely to be a passenger, while a windowon user's left can indicate that the user is more likely to be a driver,as shown in FIGS. 87C and 87E.

In another example, a user may be prompted to position a device in right(or left) landscape mode (e.g., as perceived by the accelerometer) at adistance of 30 cm-40 cm away from her face (e.g., both the presence of aface and the device's distance from face as perceived by thefront-facing camera) and point the device forward in the vehicle'sdirection of travel (e.g., as may be perceived by the rear-facingcamera, the GPS and/or the compass/magnetometer), as shown in FIG. 89A.Visual captures can be captured or otherwise acquired using thefront-facing (as shown in FIG. 89C) and rear-facing (as shown in FIG.89B) cameras of the device. The in-vehicle role of the user can then bedetermined, for example (such as in the scenario depicted in FIG. 90A),based on the angle of the hood/road border (which might be identified,for example, as a part of the rear-facing image that doesn't changesignificantly from frame to frame), e.g., a hood that has a negativeslope is more likely to have been captured by a passenger device (suchas is shown in FIG. 90D—it should be understood that FIG. 90E representsthe corresponding visual capture captured by the front-facing camera ofthe device), while a hood with a positive slope is more likely to havebeen captured by a driver device (such as is shown in FIG. 90B—it shouldbe understood that FIG. 90C represents the corresponding visual capturecaptured by the front-facing camera of the device). By way of furtherexample, the angle of the lower windshield frame or the windshieldwiper, e.g., a lower windshield frame or a windshield wiper that has anegative slope (e.g., relative to the horizon or relative to thehood-road border) can be determined to be more likely to have beencaptured by a passenger device (as shown in FIG. 90D), while a lowerwindshield frame or a windshield wiper that is determined to have apositive slope can be determined to be more likely to have been capturedby a driver device (as shown in FIG. 90B). By way of further example, ina scenario such as that depicted in FIG. 91A, a pattern on thewindshield resulting from the partial reach of the windshield wipersacross the windshield, e.g., a circular arc that is fewer than a certainnumber of degrees can be determined to more likely to have been capturedby a passenger device (such as is depicted in FIG. 91B—it should beunderstood that FIG. 91C depicts a corresponding visual capture capturedby a rear-facing camera of the device). Moreover, in a scenario such asthat depicted in FIG. 92A, upon determining that a circular arc in thevisual capture (such as that depicted in FIG. 92B—it should beunderstood that FIG. 92C depicts a corresponding visual capture capturedby a rear-facing camera of the device) is more than a certain number ofdegrees, it can be determined that the device that captured it is morelikely to be a driver device, while determining that the referencedcircular arc is fewer than a certain number of degrees can be determinedto indicate that the capturing device is likely to be a passenger device(such as is depicted in FIG. 92B—it should be understood that FIG. 92Cdepicts a corresponding visual capture captured by a rear-facing cameraof the device). By way of further example, determining the direction ofthe user's seat belt can be used to determine whether a user is a driveror a passenger, e.g., seat belt over right shoulder can indicate thatthe user is more likely to be a passenger (such as is depicted in FIG.92E), while a seat belt over left shoulder can indicate that the user ismore likely to be a passenger (such as is depicted in FIG. 92C) By wayof further example, the arrangement/placement of window(s) around theuser can be used to determine whether a user is a driver or passenger,e.g., a window on user's right (such as is depicted in FIG. 92E) canindicate that the user is more likely to be a passenger, while a windowon user's left (such as is depicted in FIG. 92C) can indicate that theuser is more likely to be a driver.

For example, a user may be prompted to position a device at a distanceof 30 cm-40 cm away from her face (e.g., both the presence of a face andthe device's distance from face as perceived by the front-facingcamera), and point the device toward and capture the face (or side offace or head) of another occupant (e.g., as perceived by the rear-facingcamera). For example, FIG. 95A depicts an exemplary scenario in which apassenger is performing the referenced operations, FIG. 95B depicts anexemplary visual capture captured by the rear-facing camera of such adevice and FIG. 95C depicts an exemplary visual capture by thefront-facing camera of such a device. By way of further example, FIG.96A depicts an exemplary scenario in which a driver is performing thereferenced operations, FIG. 96B depicts an exemplary visual capturecaptured by the front-facing camera of such a device and FIG. 95Cdepicts an exemplary visual capture captured by the rear-facing cameraof such a device. The in-vehicle role of the user can be determined, forexample, based on (a) the orientation of the device relative to Earth;and (b) the orientation of the device relative to the direction of thevehicle's movement (e.g., both as perceived by the accelerometer,gyroscope, magnetometer, compass, GPS, camera(s)), etc., e.g., if thedevice is in being held vertically (i.e., positive gravity on y-axis)and the x-axis is in the direction of the vehicle's movement, then thefront facing camera is pointed to the right and the rear facing camerais pointed to the left (with respect to the direction of the vehicle'smovement) and the device can be determined to be likely to be afront-right passenger device (the difficulty of aligning both faces atthe appropriate distance(s) without being able to preview the image islikely to be very difficult for a driver). A similar determination canbe for other two occupant combinations captured in the visual captureswhile the device is held a particular orientation.

By way of further example (such as the scenario depicted in FIG. 93A), auser may be prompted to position a device in portrait mode (e.g.,gravity on y-axis as perceived by the accelerometer) and use the rearcamera to take a visual capture that includes an entire steering wheel(or, a partial steering wheel from which it can be determined (e.g.,from the size of the partial steering wheel captured) that had it notbeen for some form of blockage (e.g., a drivers arm/hand, a seat), thenthe steering wheel would likely have been captured in its entirety). Thein-vehicle role of the user can be determined from (a) the presence ofan entire steering wheel in the rear-camera's visual capture e.g., inmany cases a the steering wheel is too close and its image in the visualcapture too large to for a driver to fully capture it (such as isdepicted in FIG. 93B, showing an exemplary visual capture captured bythe rear-facing camera of a driver device, showing the steering wheeltaking up most of the visual capture and/or not being able to becaptured in its entirety). In contrast, in the scenario depicted in FIG.93C (in which the referenced visual capture is performed by a passengerdevice), the visual capture captured by the passenger device (such anexemplary visual capture is depicted in FIG. 93D) can be determined tocontain the entire steering wheel (e.g., the steering wheel takes uponly a portion of the entire visual capture and/or the steering wheelcan be identified as being at a distinct angle). It should be notedthat, in certain implementations, the difficulty of performing suchcapture may be increased for a driver by requiring that the device socapture while being held in a particular orientation (e.g., portrait).By way of further example, the device can be determined to be operatedby a driver or a passenger based on the angle of the steering wheel inthe rear-camera's visual capture. By way of illustration, the plane of asteering wheel is likely to be relatively more parallel to the plane ofa device held by a driver (such as is depicted in FIG. 93A) andrelatively less parallel to the plane of a device held by a front-rightpassenger (such as is depicted in FIG. 93C). By way of further example,a determination as to whether the device is being operated by a driveror passenger can be made based on the size of the steering wheel (or aportion thereof, e.g., the radians in the arc of a section of theperimeter of a steering wheel) within a visual capture, e.g., the sizeof a steering wheel in the visual capture will be much smaller forrear-seat occupants (such as in the scenario depicted in FIG. 94C—itshould be noted that FIG. 94D depicts a corresponding visual capturecaptured by the rear-facing camera of the device) than for front seatoccupants (such as in the scenario depicted in FIG. 94A—it should benoted that FIG. 94B depicts a corresponding visual capture captured bythe rear-facing camera of the device).

In certain implementations, the described classifiers can be applied tovisual captures which are passively taken (i.e., without the user'srequest) from one or both cameras at opportune times, i.e., when it isdetermined that there is a higher likelihood of capturing the imagesneeded to determine the in-vehicle role of the user. Among otherreasons, this is important for reducing the device's power consumption.For example, if the user is “present”, e.g., if the screen has just beenturned on or if the user is actively engaging with the device (e.g.,touch, gesture, voice) or the device is cradled (e.g., as perceived bythe accelerometer, gyroscope, proximity sensor, light sensor), thelikelihood of capturing images useful in determining the device user'sin-vehicle role is higher than if the user is not present (e.g., thedevice is in a bag, pocket, on an unoccupied seat).

In certain implementations, once the in-vehicle role of the user isdetermined with sufficient likelihood, the user (e.g., a driver), can beprevented from attempting again for the remainder of the trip. This willreduce attempts to ‘spoof’ the techniques described herein.

In certain implementations, attempts to ‘spoof’ the described techniquesby showing the device artificial visual captures (e.g., atwo-dimensional image, a piece of hardware with front and rear visualcaptures) can be circumvented by having the device emit one or moreflashes, e.g., at certain times, for certain lengths, at certain colors,known to the device and which, if not seen in the visual, is indicativeof ‘spoofing.’

In certain implementations, the described techniques can be furtherprotected from driver ‘spoofing’ (e.g., by providing pre-recorded visualcapture) by asking the user to perform one or more actions that arevisible to one or both of the cameras at a certain time during the task.For example, prompting (e.g., audibly, visually) the user to make acertain facial expression (e.g., smile, frown, wink), which, becausethey aren't known to a spoofing device (e.g., in content or timing),will not be present in the spoofed visual capture, and the user will notpass as a passenger.

It should be noted that the described techniques may use additionallight sources (e.g., screen light, flash) as and when appropriate (e.g.,night, bad weather, poor light conditions).

It should be noted that the described techniques may need to be reversedin left-side-of-the-road driving countries like the United Kingdom.

Turning now to FIG. 21, a flow diagram is described showing a routine2100 that illustrates a broad aspect of a method for selectivelyrestricting a mobile device 105 in accordance with at least oneembodiment disclosed herein. It should be understood that in certainimplementations, including any and all of the implementations andapproaches described herein, it can be advantageous to initiallydetermine (e.g., by and/or based on inputs originating at vehicle datasystem 164) that there is a passenger present in the vehicle. It can beappreciated that if the presence of a passenger within a vehicle cannotbe initially determined, it can be more efficient to preclude any/all ofthe various methods and approaches described herein, such as those whichserve to identify the in-vehicle role of the particular user, and thussimply employ one or more restrictions based upon a determination thatthe user is likely to be the driver. Moreover, in certainimplementations, it can be advantageous to initially determine (e.g.,based on inputs originating at the mobile device 105 and/or externalsources such as vehicle data system 164) that the vehicle within whichthe mobile device 105 is present is in motion (being that certainrestrictions may be preferable/appropriate/necessary only when thevehicle is in motion).

At step 2110, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or moreinputs, substantially in the manner described in detail above withrespect to step 1710. For example, inputs originating at various sensorswithin a vehicle (e.g., seatbelt sensors, weight/movement/heat sensorsat a passenger seat, etc.) can indicate and/or be processed to determinethat a passenger is present within the vehicle. Put differently, one ormore sensors or sources (e.g., vehicle data system 164) can provideinputs and/or other such information that indicate and/or can beprocessed to determine that a vehicle is moving and/or that there areoccupants in the vehicle other than a driver. In certainimplementations, if no such inputs/notifications, etc. are received, andthus the presence of a passenger in the vehicle cannot be confirmed),any or all of the various methods described in detail herein willeffectively be precluded, as referenced above, such as by not adjustingany restriction/unlocking the device.

At step 2120, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, process the inputs(such as those received at step 2110) in order to determine a presenceof a passenger within the vehicle. That is, as referenced above, incertain implementations (which, as noted, can be employed independentlyor in conjunction with one or more of the various other implementationsand approaches described herein) one or more inputs originating at avehicle data system (e.g., OBDii or other in-car computer systems suchas seatbelt sensors, weight/movement/heat sensors in a passenger seat,etc.) can be processed to determining that there are one or morepassenger occupants in the vehicle (and/or a degree of likelihood ofsuch) and/or that more than one occupant is present in the vehicle(and/or a degree of likelihood of such).

Various aspects of the referenced communication interfaces,capabilities, etc., between in-vehicle systems and mobile devices can beemployed in order to reduce driver distraction, including distractionsoriginating from the mobile devices. For example, an in-vehicle systemthat transmits signal(s) (which can be perceived via one or more of thesensors of a device, e.g., one of its radios, microphones, camera, etc.)based on which it can be determined that a device is present within avehicle and/or allows a device to query the in-vehicle system, can beutilized, in conjunction with the device, to determine whether or notvarious functionality of the device should/should not be restricted,adjusted, etc. (e.g., to reduce distraction). Additionally, in certainimplementations, upon determining that only one occupant is presentwithin a vehicle (for example, based on inputs provided by/received fromweight sensors, heat sensors, seat belt sensors, etc.), mobile device(s)determined to be within the vehicle can, by default, are determined tobe operated by a driver, and one or more safety measures, restrictions,usage policies, etc. can be applied to/in relation to it. Upondetermining that multiple occupants are present within the vehicle (thusallowing for the possibility that a device present within the vehicle isbeing operated by a passenger), one or more aspects of the functionalityof the device can be adjusted, changed etc. (e.g., restricted in one ormore ways) that may allow for authentication/unlocking by a passenger(e.g., using one or more of the techniques described herein, such asthose which may be relatively easy for a passenger to perform butrelatively harder or impossible for a driver to perform) or which mayoccur passively, without the active involvement of the operator of thedevice).

In another embodiment, a mobile device can be configured to emit/projecta signal upon determining that it is present within a moving vehicle (asdetermined using one or more of the techniques described herein or knownto those of ordinary skill in the art). With respect to a devicedetermined to be in a moving vehicle, but that does not receive such asignal (i.e., from another device in the same vehicle), it can bedetermined that there is likely to only be one occupant present withinthe vehicle (i.e., a driver) (e.g., based on the assumption that eachvehicle occupant has at least one mobile device) and the functionalityof such a device can be restricted as appropriate. It can be appreciatedthat the accuracy of the referenced technique is likely to increase asmobile devices become even more ubiquitous (e.g., wearable devices,implantable devices, etc.).

In certain implementations, such signal can be homogenous acrossdevices, while in other implementations additional identifyinginformation (e.g., a unique ID) can be encoding in the signal, forexample, based on which it can be determined how many devices arepresent within a vehicle.

It should be noted that various techniques enable the identification ofthe presence of more than one device within a vehicle associated withthe same user (e.g., cross-device advertising techniques, such as areknown to those of ordinary skilled in the art) and/or in identifyingdevices that are being used to circumvent protection systems such asthose described herein. In doing so, various restrictions can beimplemented, e.g., to prevent a driver with access to more than onedevice into “fooling” this driver protection technique (intentionally orunintentionally) into thinking that there is more than one occupant inthe vehicle. Additionally, if it can be determined, e.g., via anotherdriver protection technique, that it is appropriate to place one or morerestrictions on a device, restrictions can also be placed on otherdevices that can be determined to be relatively likely to belong to/beused by the same user. Moreover, in some scenarios, such restrictionscan be applied to the additional devices that are likely to belong tothe same user upon determining that they are in relatively closeproximity to the primary device.

It should also be noted that one or more of the techniques describedherein can be performed at the device, at a server connected to/incommunication with the device, and/or any combination thereof.

Then, at step 2142, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, and/orremoves one or more previously employed restrictions) based on thedetermination. That is, it can be appreciated that if the presence of atleast one passenger within the vehicle cannot be determined, the variousmethods and authentication approaches described herein can beprecluded/prohibited from commencing and/or made to fail regardless ofthe result of the other components, accounting for the fact that it isunlikely that a passenger is actually present in the vehicle, and thusthe user of the device within the vehicle is likely to be the driver.

It should also be noted that in certain implementations, various of themethods and approaches described herein, such as various approaches fordetermining an in-vehicle role of a user, can operate based on a defaultassumption/setting reflecting that the in-vehicle role of the user ofthe device is a driver, until proven otherwise (through one or more ofthe various methods described herein). In certain implementations such adefault setting can optionally allow the device user unrestricted accessuntil such time as such user wants to perform certain interactions thatrequire passenger authentication.

It should also be understood that the references provided above toholding/maintaining the mobile device at a particular orientation (suchas substantially horizontal) are non-limiting, and in certainimplementations various other restrictions, methods, approaches, etc.can be employed without requiring such orientation constraint.

It should also be noted that many of the implementations describedherein can be implemented alone and/or in different combinations.

It should also be noted that in certain implementations, any of thepassenger authentication methods/approaches described herein can beconfigured to require that certain components/aspects of theauthentication methods/approaches be performed at certain times withinthe process and/or within certain amounts of time and/or for certainamounts of time (e.g., the user must begin a swipe gesture within 1second of the phone being placed in the required orientation and must becomplete the gesture within 0.8 seconds thereafter during which time,for example, the user must place a finger in a certain location of thedevice for at least 1 second).

It should also be noted that the calculations, computations, and/orprocessing operations that are required in such authentication processescan be performed at the device itself and/or can be performed at aremote device (such as at central machine 168)—or in some combinationthereof, in a manner known to those of ordinary skill in the art.

It should also be noted that in certain implementations, theauthentication approaches/methods described herein are configured toprevent/preclude requiring a passenger to re-authenticate his/her devicewhen a vehicle temporarily stops or slows down (e.g., reduces its speedbelow a certain threshold), during the course of a journey. This can bedone, for example, by requiring that a the user of the devicere-authenticate only if the vehicle within which the device is presentcan be determined to have stopped and/or maintained a slow speed (e.g.,as can be determined based on inputs originating at the GPS,accelerometer, gyroscope, vehicle data system, antennas, radiofrequencies/signals, such as those originating at one or more radiotowers, such as those utilized in implementing cellular communicationnetworks, as is known to those of ordinary skill in the art, and/orother sensors), for more than a certain amount of time. In otherimplementations, the referenced requirement for re-authentication can becorrelated with a determination that the engine of the vehicle withinwhich the device is present is still operating (e.g., based on adetermination computed by processing one or more of inputs originatingat the accelerometer, gyroscope, magnetometer and/or microphone, asdescribed herein).

In certain implementations, the context(s) (e.g., present within avehicle, etc.) that may be determined with respect to various mobile(and non-mobile) devices may depend, among other things, on informationreceived from the sensor(s) that are included within or otherwise incommunication with such devices. However, in certain scenarios it maynot be efficient (or possible) to determine a particular context of afirst device (e.g., with sufficiently the same accuracy, latency, powerconsumption, etc.) using (only) the sensors associated with the firstdevice. Accordingly, in certain implementations, such context(s) of thereferenced first device may be determined (in whole or in part) based ondeterminations performed with respect to inputs originating at one ormore second devices, such as devices that may provide complimentaryinformation (which may or may not be and conveyed directly or indirectlyto the first device).

For example, in one implementation, a parent who wants to protect achild's laptop from being used while driving, but which laptop doesn'thave the sensors needed to determine that it is in a moving vehicle withsufficient accuracy, in a scenario in which a smartphone is co-locatedin the vehicle (and is equipped with the requisite sensors tosatisfactorily determine that it is in a moving vehicle, such as in themanner described herein), such a smartphone can convey such “in avehicle” information to the laptop (e.g., via Bluetooth, Wifi, etc.),based upon which the laptop can then restrict its usage accordingly.

In another implementation, a “feature phone” (i.e., a mobile devicewithout the sensors needed to satisfactorily determine whether it is ina moving vehicle) can be protected from being used in a moving vehiclein a scenario in which a smartphone is co-located within the vehicle.For example, once the smartphone determines that it is in a vehicle(such as in the manner described herein), such a determination can beconveyed to the “feature phone” (which may then shuts itself off orrestrict itself in some other way) or a 3rd party (e.g., the featurephone's mobile operator or administrator) who can then restrict thedevice's ability to send/receive texts on the network side.

In another implementation, a company which has a policy to disallow theoperation of device cameras in certain locations (e.g., for securityreasons) may not be able to effectively implement/enforce such policy ondevices that are not able to satisfactorily self-locate. Accordingly, ina scenario in which one or more second devices (e.g., smartphones) cansatisfactorily self-locate (in whole or in part), and can be determinedto be proximate to the first device, a determination that the device ispresent within a secure area can be transmitted, based on which thecamera policy can be applied.

In another implementation, it may be advantageous to utilize more thanone second device to provide the data needed (with or withoutparticipation from a first device) to determine the context of a firstdevice. In some cases, leveraging multiple devices, if available, andbreaking down tasks across the devices can assist in improving accuracy,reducing latency and reducing power used. For example, a first seconddevice may attempt to determine a walking context of a first device(e.g., a laptop or a feature phone) using an accelerometer, whereas asecond device may attempt to determine the walking context of the firstdevice using a gyroscope. Both second devices pass their data to thefirst device (e.g., the laptop) which then makes a determination as towhether or not it is walking or to a third part (e.g., a remote server)that makes the calculation and, for example, passes the results to thefirst device or to another server.

Turning now to FIG. 22, a flow diagram is described showing a routine2200 that illustrates a broad aspect of a method for eliciting anauthentication at a mobile device 105 in accordance with at least oneembodiment disclosed herein. It should be understood that in certainimplementations, such mobile device preferably has one or moreauthentication modes, such as a first authentication mode and a secondauthentication mode. Moreover, in certain implementations, such a mobiledevice preferably has a single authentication mode having a range ofsettings/parameters that can be adjusted, as described in detail herein.

At step 2205, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs one a firstauthentication mode at/in relation to mobile device 105. By way ofexample, a first authentication mode can include a lock screen or mode(such as those referenced above at step 1710) wherein a user isprompted/required to provide alphanumeric input(s) in completion of aCAPTCHA exercise, complete an interactive puzzle, etc.

At step 2210, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, receives a firstauthentication attempt. For example, such a first authentication attemptcan include an input provided by the user in attempting toauthenticate/unlock the device, such as alphanumeric input(s) (in thecase of a CAPTCHA prompt), an input attempting to perform an interactivepuzzle, etc.

At step 2220, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes the firstauthentication attempt to determine a degree of authentication success.For example, in the case of a CAPTCHA prompt, the first authenticationattempt (that is, the alphanumeric characters input by the user) can beprocessed to determine the degree to which the input was successful inperforming the task required to authenticate the device (such as thepercentage of characters in the CAPTCHA prompt that were properly inputby the user).

At step 2225, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs a secondauthentication mode based on the first authentication attempt. That is,it can be appreciated that in a scenario where the first authenticationattempt did not successfully authenticate the device and/or where thefirst authentication attempt did not meet a certain degree ofauthentication success (e.g., inputting at least 70% of the charactersin the CAPTCHA prompt correctly), a second authentication mode can beemployed. In certain implementations, such a second authentication modepreferably entails an authentication mode that is more restrictiveand/or more difficult to authenticate than the first authenticationmode. For example, the second authentication mode can require a certaindelay (e.g., 30 seconds) before another authentication attempt can bereceived at the mobile device. By way of further example, a secondCAPTCHA prompt can be presented requiring the user to input more lettersthan the first CAPTCHA prompt, and/or to input such letters moreaccurately, in order to authenticate/unlock the device.

At step 2226, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, maintains a log ofauthentication attempts. At step 2230, processor 110 executing one ormore of software modules 130, including, preferably, restriction module171, transmits one or more notifications regarding one or moreauthentication attempts, such as to a third party. It can be appreciatedthat in doing so, such authentication attempts can be monitored, andusers who consistently fail to authenticate their devices can beidentified as potentially attempting to authenticate their devices whiledriving.

By way of further illustration, it can be appreciated that in certainimplementations, such as those described above, it can be advantageousto make passenger authentication attempts, which come after failures toauthenticate, increasingly/progressively difficult. In certainimplementations, this can be achieved by requiring that a certainamount/duration of time elapse before a device, whose authentication hasfailed, can elicit and/or receive a re-authentication attempt. Such timecan also be configured to increase progressively after eachauthentication failure. Moreover, in certain implementations, suchauthentication failures can be reported one or more third parties.Moreover, in certain implementations, such authentication failures canentail one or more dynamic changes/adjustments to the parameters of thevarious techniques required to successfully authenticate (e.g., thedevice must be more stable on successive attempts in order toauthenticate).

It should also be noted that in certain implementations the details ofthe passenger authentication can be reported/transmitted to one or morethird parties, and corresponding logs can be established/maintained forthem.

Turning now to FIG. 23, a flow diagram is described showing a routine2300 that illustrates a broad aspect of a method for eliciting anauthentication at a mobile device 105 in accordance with at least oneembodiment disclosed herein. It should be understood that in certainimplementations, such mobile device preferably has one or moreauthentication modes, such as a first authentication mode and a secondauthentication mode. Moreover, in certain implementations, such a mobiledevice preferably has a single authentication mode having a range ofsettings/parameters that can be adjusted, as described in detail herein.

At step 2310, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, receives one or moreinputs, substantially in the manner describe in detail above withrespect to step 1710. Examples of such inputs include, but are notlimited to, inputs relating to speed, location, road type, time of day,weather conditions, traffic conditions, (as received, perceived and/ordetermined based on one or more inputs of the sensors of a particulardevice, information and/or data received from one or more externalsensors and/or devices, such as, for example, external data streams, RSSfeeds, and/or databases, such as those accessible over a GPRS dataconnection, and/or computations and/or determinations that are computedbased on one or more of such inputs, information, data, etc.).

At step 2320, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes theinput(s) to compute one or more determinations. Preferably thedeterminations reflect a degree to which a user, such as a user in amoving vehicle, is likely to be capable of multitasking and/or isdistracted and/or is potentially distracted or distractible. Forexample, it can be determined that a user of a device present within avehicle moving at a high rate of speed is likely to be more distracted(such as in scenario where such a user is the driver, on account of theincreased concentration that the driver must dedicate to driving at ahigher speed) and/or subject to the increasing force(s) (such as in ascenario where such a user is a passenger, especially while the vehicleis moving laterally), more so than a user in a vehicle moving at arelatively lower rate of speed.

At step 2330, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs anauthentication mode at the mobile device based on the determination. Itshould be understood that in certain implementations such anauthentication mode can include multiple parameters, settings, and orconfigurations, while in other implementations such an authenticationmode can be selected from among multiple distinct authentication modes,such as a first authentication mode and a second authentication mode.For example, as referenced above, it can be appreciated that a driverpresent in a vehicle moving at a relatively high rate of speed is likelyto be potentially more distracted, and thus relatively less able than adriver present in a vehicle moving at a relatively low rate of speed toprovide even a relatively simple authentication (while, at the sametime, a passenger in such a vehicle can be similarly limited, on accountof the forces imposed on the user while riding in such a fast movingvehicle). It can be similarly appreciated that a user traveling within avehicle moving at a relatively slower rate of speed is likely to be morecapable of multitasking, even while driving, than a comparable usertraveling within a vehicle moving at a relatively faster rate of speed,and thus can be determined to be relatively less distracted than such acomparable user traveling in a vehicle moving at a relatively fasterrate of speed. As such, in certain implementations, one of the variousauthentication modes and/or settings thereto can be employed/selectedbased on a determination that reflects the likelihood that the useris/is not distracted/able to multitask. Thus, by way of illustration, incertain implementations, when the vehicle is moving at a relativelyslower rate of speed, an authentication mode/setting requiringrelatively more concentration/attention can be employed (such as aCAPTCHA prompt requiring six letters to be correctly/accurately input inorder to authenticate/unlock the device), and when the vehicle is movingat a relatively faster rate of speed, an authentication mode/settingrequiring relatively less concentration/attention can be employed (suchas a CAPTCHA prompt requiring only four letters to becorrectly/accurately input in order to authenticate/unlock the device)can be employed.

By way of further illustration, it should be noted that any and all ofthe implementations, methods, and approaches described herein, includingthose enumerated above, can also be employed in a manner whereby thedifficulty of the task presented to and/or required of a user in orderto authenticate the in-vehicle role of a user as a passenger (includingthe time needed for a user to perform an action in order to soauthenticate his/her identity as a driver or passenger, and/or the timelimit within which the user is required to so authenticate), can bedetermined and/or adjusted dynamically based upon any number of factors.By way of example, factors such as speed, location, road type, time ofday, weather conditions, traffic conditions, (as perceived and/ordetermined based on one or more inputs of the sensors of a particulardevice, information and/or data received from one or more externalsensors and/or devices, such as, for example, external data streams, RSSfeeds, and/or databases, such as those accessible over a GPRS dataconnection, and/or computations and/or determinations that are computedbased on one or more of such inputs, information, data, etc., such as inthe manner described in detail herein) can be considered and/orprocessed in order to determine and/or adjust one or more operationalparameters of a particular authentication task/mode or tasks/modes, asdescribed above. For example, in a scenario where the vehicle withinwhich the user is traveling is moving at a relatively slow speed, theuser can be required to complete an authentication task within arelatively shorter time limit (as compared to when the vehicle is movingat a relatively faster speed), thereby accounting for the fact that whentraveling at a slower speed, a driver may be able to divert his/herattention from driving for a relatively longer time interval (ascompared to when driving faster). As such, the time limit within whichthe authentication task must be completed can be reduced at lowerspeeds. (Similarly, it can be appreciated that when traveling at fasterspeeds, a passenger may require additional time to complete anauthentication task, accounting for the additional forces attendant withtravel at higher speeds.) By way of further illustration, in certainimplementations the duration of time during which a particularauthentication task must be performed can also be adjusted dynamicallybased on any number of factors, such as those referenced above. Forexample, when a vehicle is traveling at a relatively slower speed, auser can be required to hold his/her gaze into a camera of a mobiledevice for a relatively longer period of time than such authenticationmay require when traveling at relatively faster speeds. Being that atslower speeds a driver may be able to divert his/her attention fromdriving for relatively longer periods of time (as referenced above), theauthentication task/mode can be adjusted (such as by requiring that thetask be performed continuously for a longer period of time) in order toaccount for this discrepancy/difference. It should also be noted that incertain implementations, the particular authentication task required ofa user (e.g., a swipe unlock gesture, a puzzle, etc.) can be changed orsubstituted depending on the various factors referenced above. Thus, forexample, at one speed a swipe unlock gesture can be required in order toauthenticate the user as a passenger, while at another speed a puzzlemust be completed in order to complete such authentication.

Moreover, in certain implementations one or more of the authenticationtasks/modes referenced herein can be stopped prematurely and/orcontinued indefinitely depending upon inputs received from one or moresensors that correspond to behavior of a user. For example, if, at somepoint prior to the end of such a task, the device is determined to belikely to be operated by a driver (e.g., the device or aspects thereofare moving in a certain manner that can be determined to resemble thatof a driver, such as (a) a relatively significant amount of ‘shaking’ ascan be measured/determined based on inputs originating at theaccelerometer and/or gyroscope of the device and/or (b) the manner inwhich the user input is provided can be determined to more closelyresemble that of a driver, such as based on relatively inexact keypresses, time to press keys, etc.), (a) the task can automatically beended prematurely in failure, (b) the task can be scored/registered asfailed, even despite the fact that the user may have completed theactual task successfully (and vice versa), and/or (c) the tasklength/time/difficulty is dynamically changed (i.e., the time in whichthe user must complete the task can be lengthened or shortened, thedifficulty of the task can be increased or decreased, etc.), such as inthe manner described herein.

In certain implementations, the authentication task can include elementsthat may require a response to be provided by the user (e.g., numbersthat are presented on the display screen of the device for a fixed ordynamic/random period of time), whereby (a) the element location on thedevice screen contains or otherwise incorporates a random or varyingcomponent/aspect (e.g., elements are placed in different locations onthe device display screen on different passenger authenticationattempts), (b) the element sizes contain or otherwise incorporate arandom or varying component/aspect, (c) the element orientations containor otherwise incorporate a random or varying component/aspect (e.g.,they can rotate around an axis, reflect through an axis, etc.), (d) thetime between the presentation of elements contains or otherwiseincorporates a random or varying component/aspect, and/or (e) the timeduring which the element remains on device's display screen contains orotherwise incorporates a random or varying component/aspect. It shouldalso be understood that, in certain implementations, the referenced taskelements can be arranged in a static manner (e.g., element 1 is placedat location A, in orientation B for as long as it appears) or can bearranged in a dynamic manner (e.g., element 1 is placed on the devicedisplay screen at location A and in orientation B, but moves fromlocation A to some other location (along any path, even a non-continuousone) and/or changes its on-screen orientation from orientation B to someother orientation (e.g., in any way, even if not necessarilycontinuous), such as for as long as it appears.

In certain implementations, the difficulty of any of the authenticationtasks described herein can be adjusted (e.g., up or down), such as basedupon the age of the user of the device (as can be determined, forexample, based on the adeptness of the user at completing such tasks).It can be appreciated that in many scenarios relatively younger userswill be more adept than older users. In addition, users who activelyengage in activities that are similar to such task (e.g., game playing,etc.), will be able to perform the task faster and with fewer errorsthan those who do not.

As such, for example, the younger and/or more adept a user can bedetermined to be, the harder the passenger authentication task that canbe presented to such user. For example, (a) the time to complete thetask will be shorter for a younger and/or more adept user than for anolder and/or less adept user, and/or (b) the substance of the task to beperformed by a young and/or adept user can be more difficult than thatfor an older and/or less adept user.

The age and/or adeptness of the device user may be (a) identified (e.g.,having been provided by a parent, an employer, etc.), (b) discovered(e.g., from auto-fill settings, social network information), (c)determined/estimated (e.g., based on the applications (e.g. games),installed on the device, the number of texts sent on average per unit oftime, the type of e-mail accounts on the device (e.g., work/corporatevs. not work), the existence of any connections that might suggestcorporate citizenship (e.g., Exchange/APN/VPN), the hours of activity,the speed of typing, the maturity of the prose used in messages, or anyother such indicators of the age/adeptness of a user of the device)and/or (d) learned (e.g., adjusted dynamically based upon the adeptnessdisplayed in relation to the device, such as in previous passengerauthentication task attempts).

Additionally, in certain implementations, an authentication task canrequire that at least one hand of the user be constantly engaged withthe device for substantially the entire task. For example, the user canbe prompted to place a finger on a certain part of the screen (whichpart of the screen may not be the same from trial to trial) or a certainbutton which the user is required to hold throughout the task (or elsethe task may end in failure), such as in the manner described herein inrelation to FIG. 15A. Alternatively, the user can be required to performa gesture with one hand, and to maintain the gesture throughout the taskin a manner that is perceptible by the device (e.g., by a camera).

In yet other embodiments, different tasks can be assigned to each of auser's hands. For example, one hand can be required to perform a fixedtask (e.g., maintaining contact with a particular area of the device,such as the screen, as described above), while the second hand isrequired to perform a non-fixed task (e.g., typing).

It should also be noted that, in certain implementations, it can beadvantageous to allow passengers to be authenticated by 3^(rd) parties,despite previous failed, inconclusive, incomplete, or non-existentauthentication attempts, such as the results of one or more of the abovereferenced methods. For example, if mobile device 105 is damaged ormalfunctions (e.g., due to a broken sensor, environmental disturbancessuch as weather conditions affecting the performance of the GPS, etc.)thereby precluding various of the authentication methods/approaches(such as those described herein) from being employed effectively, athird party such as an employer or a parent can remotely provide suchauthentication, such as in a manner known to those of ordinary skill inthe art.

It should also be noted that various of the methods described herein aredescribed with reference to a road system where the cars travel on theright-side of the road and where drivers are seated on the left-side ofthe vehicle. However, it should be understood that the methods describedherein are not so limited, and can be similarly employed/transferred toother road systems (such as that of the United Kingdom).

Turning now to FIG. 24, a flow diagram is described showing a routine2400 that illustrates a broad aspect of a method for selectivelymodifying a restriction employed at a mobile device 105 in accordancewith at least one embodiment disclosed herein.

At step 2410, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, receives one or moreinputs, substantially in the manner describe in detail above withrespect to step 1710. For example, such inputs can originate at theaccelerometer and/or gyroscope of the mobile device 105, and reflect themovement/motion that the device perceives.

At step 2420, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes theinput(s) to compute one or more trends/patterns. By way of example,inputs, such as those received at step 2410, can be processed todetermine one or more patterns, such as those that correspond to drivingand/or walking (e.g., by comparing the various inputs to operationsignatures that correspond to such activities, as is known to those ofordinary skill in the art). In doing so, one or more trends/patterns canbe computed, such as a trend/pattern that reflects that the user of thedevice is now walking. By way of further illustration, a trend/patterncan be computed reflecting the docking status of a mobile device, suchas in the manner described in detail herein.

At step 2442, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, and/orremoves one or more previously employed restrictions) based on the oneor more trends/patterns. For example, in certain implementations,despite having previously determined that the user of mobile device 105is a driver of a vehicle (and thus employing one or more restrictions onsuch a device), upon computing one or more trends/patterns that indicatethat the user of the device is now walking (and thus is no longerdriving a vehicle), such previously imposed restrictions can beadjusted, eased, removed, etc. By way of further illustration, based ona determination of the docking status of a device, as described indetail herein, one or more restrictions appropriate for a docked device(e.g., a restriction that prohibits voice calls to be made/conducted)can be modified/eased/lifted.

By way of further illustration, in certain implementations, after adevice is placed in driver mode (e.g., the user of the device beenauthenticated as a driver and/or the device and/or restriction areconfigured such that the device operates by default in driver mode,until the user can prove otherwise by way of one or moreauthentications, such as through the methods described herein) a furtherdetermination can be made with regard to whether the device remains oris no longer in a moving vehicle. In doing so, some or all of variousrestrictions referenced herein, e.g., operation of a mobile device in a‘driver mode,’ can be suspended and/or canceled, thus returning thedevice to its default, un-restricted operation. In variousimplementations, such a determination can be computed (for example,using inputs originating at one or more of the GPS, the accelerometer,the gyroscope, and/or the RF transceiver/antenna to know which celltowers the device is in communication) based on (a) whether the vehiclehas not moved above a certain speed for more than a certain period oftime; and/or (b) whether the vehicle has not moved above a certain speedfor more than a certain portion over a period of time (the ‘timeoutperiod’). Additionally, in certain implementations, a user who waspreviously identified as a driver can be enabled to authenticate thathe/she is no longer the driver of a moving vehicle in order not to haveto wait the full timeout period before regaining full control over thedevice. In certain implementations, this can be achieved, for example,(a) by holding the device so that the camera of the device can capture(and recognize, such as with face recognitions methods, as are known tothose of ordinary skill in the art) the presence of a face (or eyes orgaze etc.) and by then rotating 360 (or more or fewer) degrees, asmeasured by device's sensors (e.g., magnetometer, gyroscope,accelerometer, etc.), during which time the camera perceives the face(or eyes or gaze etc.); (b) by touching the device in a manner that canbe detected (e.g., touching the screen, holding a button, etc.) and bythen rotating 360 (or more or fewer) degrees, while the user maintainshis/her touch or hold on the device; (c) by moving the device (e.g., up,down, sideways) a distance greater than the distance that a driver in amoving vehicle is able to as measured by the device's sensors (e.g.,accelerometer, gyroscope, etc.); and/or (d) by taking a visual capturefrom close range of a license plate (such a visual capture can beprocessed to identify an indication of a degree of close proximity of alicense plate. It can be appreciated that a driver of a moving vehicleis likely to be incapable of capturing a visual capture within closeproximity of a license plate).

It can be appreciated that the referenced techniques are preferablyactions or tasks that are difficult, if not impossible, for a user toperform while he/she is still the driver of a vehicle.

FIG. 59 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 5910, a trip initiation instance can be identified. Such a tripinitiation instance can be, for example, an occurrence with respect towhich it can be determined that a trip (e.g., traveling in a vehicle)has begun and/or is currently underway. In certain implementations, sucha trip initiation instance can be identified using one or more ‘tripstart’ identification/determination techniques described herein.Moreover, in certain implementations, such a trip initiation instancecan be identified with respect to a device (e.g., a smartphone presentwithin a vehicle).

At 5920, a trip conclusion instance can be identified. Such a tripconclusion instance can be, for example, an occurrence with respect towhich it can be determined that a trip (e.g., traveling in a vehicle) isending/has ended. In certain implementations, such a trip conclusioninstance can be identified using one or more ‘trip end’identification/determination techniques described herein. In certainimplementations, such a trip conclusion instance can be identified withrespect to the device (e.g., the device with respect to which the tripinitiation instance was identified at 5910).

At 5930, a determination that a user of/associated with the device islikely to be a driver or a passenger can be computed. In certainimplementations, such a determination can be computed using one or moretechniques described herein (e.g., user role determination techniques).

At 5940, one or more actions or operations can be initiated. In certainimplementations, such actions/operations can be initiated subsequent toidentifying the trip conclusion instance (e.g., at 5920). Moreover, incertain implementations such actions can be initiated in relation to thedevice and/or the user. Moreover, in certain implementations suchactions can be initiated based on/in response to a determination thatthe user of the device is likely to a driver or a passenger.

Examples of such action(s) can include actions that are not necessarilyrelated to device restrictions. Moreover, in certain implementationssuch action(s) may be related to the device (e.g., send a message fromthe device to another party or entity) or not related directly to thedevice (e.g., charge an insurance policy). It should be furtherunderstood that such actions(s) may be tailored or configured to aparticular context, setting, and/or industry. For example, with respectto a ‘pay as you go’ insurance policy/company, the determination as towhether the user of the device (which was determined to previously havebeen in a trip) was the driver or the passenger can dictate whether theinsurance company will or will not charge the user for the trip (asdescribed in greater detail below). In a corporate/enterprise context,the determination as to whether the user (e.g., an employee of thecompany) of the device (which was determined to previously have been ina trip) was the driver or the passenger can be reported to the employerand/or used to determine whether the employee is complying with companypolicy (e.g., that drivers should not use their devices in certain wayswhile driving). In a parent/child context, the determination as towhether the user (e.g., a child) of the device (which was determined topreviously have been in a trip) was the driver or the passenger can bereported to the parent and/or used to determine whether the child iscomplying with a policy dictated by the parent and/or the law (e.g.,that drivers should not use their devices in certain ways whiledriving). In a regulatory/law enforcement context, the determination asto whether the user (e.g., a citizen) of the device (which wasdetermined to previously have been in a trip) was the driver or thepassenger can be reported to an agency and/or used to determine whetherthe user is complying with a policy recommended and/or required by law(e.g., that drivers should not use their devices in certain ways whiledriving).

By way of illustration, it can be appreciated that in some cases it maybe advantageous to identify/determine the role of the user of a device(e.g., as a driver or passenger) that is (or has been) present in atrip, such as using one or more of the techniques described herein, evenif such determination is only made after the trip has begun or evenafter the trip has ended (e.g., for reasons of accuracy, power,performance). In some cases such role determination may be achieved withhigher accuracy (and/or lower power consumption) after additional inputsfrom one or more sensors and/or radios (and/or alternative, lower powersensors) have become available/received and/or analyzed. For example,with respect to an insurance company that charges its policyholdersbased upon the amount they drive (e.g., “Pay How Much You Drive”insurance) and utilizes the policyholder's mobile devices to helpmonitor how much the policyholder drives (e.g., in time, distance, etc.)it can be advantageous to determine/identify whether the policyholderwas the driver (in which case they will be charged) or the passenger (inwhich case they will not be charged) during each trip. In many cases,however, it is not necessarily imperative that such determination bemade (or verified) close to the beginning of the trip—it is sufficientthat the determination be made later into the trip or at (or after) theend of the trip (in particular if making such a determination later canhelp improve the accuracy of such determination). In another example,the described techniques can be implemented by a driver safety researchorganization which wants to be able to test the effect of certaineducational policies on device use by drivers. In order to do so, itwishes to identify certain behaviors as dangerous only when the user isa driver, but there is no significant advantage to making suchdetermination at or near the start of a trip.

Moreover, in certain implementations the in-vehicle role of a user canbe used in order to further determine whether a set of data should beincluded or not used/included in calculating one or more furtherdeterminations/scores (e.g., a driver score), which can be used to givefeedback (e.g., to drivers, 3rd parties like employers or parents) orcan be used as a factor to price vehicle insurance premiums (e.g., byinsurance companies).

In certain implementations the relationship between the use of thedevice and the speed at which the vehicle is traveling can be used indetermining the in-vehicle role of the device user. For example, deviceuse by drivers happens relatively more frequently at lower speeds thanpassenger device use (e.g., relative frequency of driver use is higherthan passenger use at red lights).

In certain implementations, a user of a restricted mobile device (e.g.,a mobile device that is restricted in one or more ways, such as when thedevice is determined to be present within a vehicle and/or a trip, untilthe user successfully verifies that he/she is a passenger, such as in amanner described herein), such as a device that is present within avehicle/trip, can be determined/identified/assumed (e.g., by default)that if/so long as the user does not verify him/herself as a passenger,they are the driver. Such a determination/identification/assumption canbe provided to one or more other services or third parties, includingbut not limited to: (a) an application (e.g., executing at the device orremotely) pertaining to a usage-based insurance product which may takevarious action(s) depending on whether the policyholder is determined tobe the driver (e.g., in which case his/her driving behavior may belogged and/or scored and factor into his/her insurance premium) or apassenger (in which case it will not); (b) an application (e.g.,executing at the device or remotely) pertaining to a “per-mile” or“per-hour” based insurance product which may take various action(s)depending on whether the policyholder is the driver (e.g., in which caseshe may be charged an insurance premium for such trips) or a passenger(in which case she will not). Moreover, in certain implementations thereferenced determination/identification/assumption (e.g., reflectingthat a user who doesn't verify as a passenger over the course of a tripis in fact a driver) can be weighted or scored (reflecting, for example,the a degree of likelihood or certainty with respect to thedetermination/identification/assumption), and such a weight/score can beincreased based on various factors including but not limited to: (a) thedistance of the trip (the longer the trip, the more likely a user whodoes not authenticate as a passenger is likely to be a driver), (b) themore active a mobile device user the user is (the more active the useris, the more likely it is that if the user does not authenticate, thathe/she is likely to be a driver), and/or (c) the higher the frequency atwhich the user verifies as a passenger when she is a passenger (the moreoften the user authenticates as a passenger, the more likely is that ifthe user does not authenticate, that he/she is likely to be a driver),and the converse.

FIG. 54 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 5410, it can be determined that one device is connected or otherwiselinked to another device, (e.g., an in-vehicle system). For example,various technologies and protocols enable the connection of a mobiledevice to an in-vehicle system (e.g., an infotainment system, acommunication system, etc.), such as MirrorLink, AppLink, Sync,Intelilink, ConnectedDrive, and others. In many such vehicle systems,when a device is connected, the device can/must cede/relinquish some orall control of the device to the vehicle system for as long as it isconnected (or, in certain implementations, for as long as the vehicle ismoving, ignited, and/or in gear). It can be further appreciated thatsuch vehicle systems can be configured in a manner that reduces userdistraction (e.g. based on NHTSA Phase I guidelines).

Accordingly, in certain implementations, a mobile device determined tobe connected to a vehicle (e.g., to one of such in-vehicle systems) canbe identified/determined to be relatively less distracting (e.g., byvirtue of the configuration of the system to which is connected and/orthe manner in which such a system can control/override operation(s) ofthe mobile device, e.g., in view of various safety guidelines that thesystem is configured with/based on), as compared to a device that ispresent within a vehicle but not connected to, an in-vehicle system.

At 5420, one or more restrictions can be employed, such as at/withrespect to the device. In certain implementations, such restrictions canbe employed based on a determination that the device is no longerconnected to the in-vehicle system. That is, it can be appreciated thatthe referenced reduction in driver distraction (e.g., based on aconnection of the device to such a system configured based on varioussafety guidelines) may be ephemeral, as a user may simply disconnect themobile device from the in-vehicle system to release/remove any suchrestriction(s). Accordingly, in certain implementations, upondetermining that a device is disconnected from an in-vehicle system(e.g., by sensing the termination of a wired or wireless connection onthe device), one or more restrictions can be employed (and/or continueto be employed) at/in relation to the device, e.g., for as long as oneor more conditions are met (e.g., the device is determined to remain ina moving vehicle, the device is determined to remain in an ignited, orin-gear vehicle). Alternatively, in certain implementations, suchrestrictions can be employed at/in relation to the device until suchtime as one or more other conditions can be determined to be met (e.g.,the vehicle is no longer moving, the device is no longer in the vehicle,the vehicle is no longer ignited, the vehicle is no longer in gear,etc.). It should be understood that the detection of these variousconditions and states can be achieved, for example, using one or more ofthe techniques described herein or until the user is identified as orauthenticates as a passenger (e.g., in the event that the device thatwas disconnected is being used by a passenger), using, for example, oneor more of the techniques described herein.

At 5430, one or more restrictions (such as those employed at 5420) canbe adjusted or otherwise modified. In certain implementations, suchrestrictions can be adjusted (e.g., eased, loosened, removed, etc.)based on a determination that the device has been reconnected to thein-vehicle system.

At 5440, the referenced restrictions (such as those employed at 5420)can be maintained. In certain implementations, such restrictions can bemaintained for as long as the vehicle in which the device is determinedto present is determined and/or perceived to be in a trip (as determinedusing one or more of the techniques described herein).

At 5450, one or more restrictions (such as those employed at 5420) canbe adjusted. In certain implementations such restrictions can beadjusted based on a perception of one or more changes in an operation ofa vehicle, such as a vehicle associated with the referenced in-vehiclesystem (e.g., the vehicle in which the device is present/traveling).Examples of such changes include but are not limited to changes thatpertain to an ignition state of the vehicle (e.g., whether the carand/or its engine is on or off), and/or an in-gear state of the vehicle(e.g., whether the vehicle is in ‘drive’ or ‘park’).

FIG. 55 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 5510, it can be determined that a first device (e.g., a smartphone,mobile device, etc.) is proximate (or is relatively likely to beproximate to) to a second device (e.g., within a certain distance,radius, etc. of the second device). As described herein, such a seconddevice can be, for example, one or more wireless hardware components(e.g., WiFi access point, Bluetooth devices, speakers, NFC, etc.).

At 5520, one or more trip detection techniques (such as those describedherein) can be employed. In certain implementations, such trip detectiontechniques can be employed based on a determination (e.g., at 5510) thatthe first device is proximate to and/or can otherwise perceive thesecond device (and/or can perceive signals, such as wireless signals,which originate from the second device). For example, having determinedthat a mobile device can perceive a particular access point (e.g., anaccess point within the vehicle), one or more trip detection techniquescan be employed, in order to determine whether the device is presentwithin a trip. Moreover, in certain implementations, one or more of suchtrip detection techniques can be adjusted based on a determination(e.g., at 5510) that the first device is proximate to and/or canotherwise perceive the second device (and/or can perceive signals, suchas wireless signals, which originate from the second device).

Moreover, it should be understood that in certain implementations thedetermination that the first device is proximate to the second devicecan reflect that the first device is relatively likely to be present ina trip (e.g., in a vehicle that is currently traveling). By way ofillustration, in certain implementations, in addition to (or instead of)the various other techniques described herein (which may detect ordetermine when a mobile device is present within a moving vehicle), anassociation or correlation between various characteristics (e.g., IDs,signal strengths, transmission channels, frequencies, etc.) of one ormore hardware components (e.g., wireless components, WiFi access points,Bluetooth devices, speakers, NFC, etc.) that are present within thevehicle (whether original equipment or after-market, whetherprofessionally-installed, user-installed or otherwise present within thevehicle without requiring installation or without having been installed)and various device movement characteristics (e.g., within a trip, not ina trip) can determined (and/or learned over time, such as using machinelearning techniques as are known to those of ordinary skill in the art).When one or more of the referenced devices (e.g., wireless hardwarecomponents that has been associated with particular device movementcharacteristics is perceived or otherwise observed (e.g., detecting thata certain WiFi access point is in range of the mobile device), adetermination may be made as to whether the device is in a trip. Forexample, if the 14 of the last 15 times that (i) input(s) from one ormore of the device's motion sensors (e.g., accelerometer, GPS, etc.)indicated/reflected that it was relatively likely that the device was ina trip (e.g., greater than a certain threshold value), and (ii) thedevice was concurrently (or within a certain time interval) determinedto be in the presence of MAC address 11:22:33:44:55:66 with a signalstrength greater than −80 dbm, upon subsequently determining that thedevice is again in the proximity of this MAC address (and its signalstrength is sufficiently high), it can be determined, concluded, orotherwise assumed that the device is again within a moving trip (e.g.,even without utilizing other trip detection techniques, such as based oninputs from one or more motion sensors). Such techniques can beadvantageous, for example, in a scenario in which the power consumptionof various motion sensors is higher than that of sensing wirelesshardware components (e.g., scanning, listening), such that tasksassociated with motion detection are performed after an initialperception (e.g., of an access point, etc.).

In another implementation, an initial indication of movement (e.g.,based on inputs from various sensors such as an accelerometer, etc.) canfirst be identified/determined, and having determined that motion ispresent (e.g., there is an increased likelihood that the device may bewithin a trip), a further determination can be made with respect towhether the device can perceive/is in proximity to a hardware device(e.g., a wireless access point, etc.). Such techniques can beadvantageous, for example, in a scenario in which the power consumptionof various motion sensors is lower than that of sensing wirelesshardware components (e.g., scanning, listening), such that tasksassociated with motion detection are performed prior to attempting toperceive/identify hardware devices (e.g., an access point, etc.).

At 5530, one or more notifications can be provided. In certainimplementations, such notifications can be provided in relation to thefirst device. For example, in certain implementations such notificationcan be provided based on a determination (e.g., at 5510) that the firstdevice (e.g., the mobile device) is no longer proximate to (or can nolonger perceive) the second device (e.g., an access point).

By way of illustration, in certain implementations when (i) a mobiledevice is within a certain proximity to a wireless in-vehicle hardwarecomponent and/or (ii) after a trip start has been determined (e.g.,using one or more techniques described herein), the device can beconfigured to notify/query the user as to whether there is a young childin the vehicle (who might not be able to exit the vehicle on her own).If the user indicates that there is one or more such children in thevehicle, when it is subsequently detected/determined that the device isno longer within the referenced proximity to the same hardware component(e.g., WiFi access point, etc.) and/or that a trip has stopped, thedevice can notify or query the user to confirm that the young child hasbeen removed from the vehicle. The device may also send one or moreelectronic updates or notifications (e.g., text, data, voice, etc.) toone or more third parties (e.g., a worried mom) reflecting thereferenced status.

FIG. 56 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 5610, a proximity instance to a first device can be associated. Sucha proximity instance can be, for example, an instance of a first device(e.g., a smartphone) being determined to be within a defined proximity(and/or being capable of perceiving, such as in the case of a WiFiaccess point or any other such wireless transmitter/receiver) of asecond device (e.g., an access point, Bluetooth transmitter/receiver,etc.), and may be associated with a trip state such as ‘within a trip.’As described in detail herein, upon determining or otherwise identifying(e.g., based on one or more prior observations) that a particularproximity instance is associated, correlated and/or otherwise coincideswith various other inputs (e.g., motion inputs, such as may originatefrom an accelerometer, GPS, etc.) that reflect and/or that can be usedto determine a trip state (e.g., whether a vehicle is or is notcurrently in a trip), it can be further determined that subsequentidentifications of such a proximity instance can be associated with acomparable trip state (e.g., even without affirmatively confirming thetrip state, e.g., via inputs from the accelerometer, GPS, etc.).

At 5620, one or more actions can be initiated. In certainimplementations, such actions may be associated with the trip stateassociated with the proximity instance. Moreover, in certainimplementations such actions can be initiated based on an identificationof the proximity instance with respect to a second device (e.g., a Wifiaccess point). For example, upon identifying, with respect to aparticular device (e.g., a smartphone) a proximity instance with respectto another device (e.g., a WiFi access point) that has been associatedwith a particular trip state (e.g., ‘within trip’), such a trip statecan be imputed or otherwise applied or associated with the device (e.g.,smartphone), and one or more actions (which may depend or be triggeredby the trip state—such as device restrictions or authenticationtechniques) can be initiated.

In certain implementations, instead of, or in addition to querying thedevice user, a determination can be suggested or made as to whether ornot there is a young child in the vehicle and/or whether or not theyoung child left the vehicle, such as based on inputs originating fromvarious vehicle occupant sensors in the car (e.g., weight sensor, heatsensors, seat-belt sensor).

Turning now to FIG. 18, a flow diagram is described showing a routine1800 that illustrates a broad aspect of a method for selectivelyrestricting an operation of and/or selectively modifying a restrictionemployed at mobile device 105, such as within a geographic area and/or adate/time window, in accordance with at least one embodiment disclosedherein. As will be described in detail herein, it can be appreciatedthat under certain circumstances (e.g., within defined spaces and/ortimes) it can be advantageous to control and/or influence the operationof one or more mobile devices 105, 160 in various ways, such as byconfiguring such devices to operate in a highly conspicuous/overtfashion. For example, considering the distracting nature of mobiledevice usage during class (particularly when used in an inconspicuousfashion), it can be advantageous for a school to require that itsstudents only operate mobile devices 105, 160 during school days/timeand/or on school locations/grounds and/or in certain location withinschool grounds (e.g., classrooms) in a manner that is highlyconspicuous, thereby effectively precluding the inconspicuous usage ofsuch devices 105, 160 in settings where their use is undesirable.

At step 1811, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 generates one or moreoutput(s), such as an audio output (such as a beep or chirp) that isprojected through speaker 146 of mobile device 105. It should beunderstood that such outputs can be configured/adjusted in any number ofways (e.g., in frequency, duration, and/or volume), both with respect totheir substance (e.g., chirps, beeps, tones, etc.) and the periodicinterval within which they are projected (static and/or dynamic). In anyevent, it should be understood that such outputs are preferablyprojected at volumes and for durations such that inconspicuous operationof mobile device 105, 160 is effectively precluded (e.g., in a classroomsetting) on their account. Moreover, in certain arrangements it can bepreferable that such outputs are not so loud and/or so frequent so as tosignificantly annoy the user and/or those around them while using mobiledevice 105, 160 in a permitted setting. At this juncture, it should alsobe noted that in certain arrangements, one or more of the referencedoutputs can be generated in response to one or more inputs, as will bedescribed in greater detail below. It should also be noted that, incertain implementations, the referenced device can be configured togenerate/project such audio output(s) (e.g., ‘chirp(s),’ etc.)irrespective of one or more other settings (e.g., audio settings)associated with the device (so, for example, the device can continue to‘chirp’ even when set to silent/vibrate mode).

At step 1812, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, receives one or moreinputs. For example, in certain implementations one or more of theoutputs projected by mobile device 105 (such as through speaker 146, asdescribed with reference to step 1811) can, in turn be received, asinputs, at the mobile device, such as through microphone 145D.

By way of further example, in other implementations the one or moreinputs can correspond to various user interactions with the device, suchas tactile interactions (e.g., with one or more tactile sensors such asone or more buttons, a touchscreen, etc., as describe in detail herein)or device movements. Upon receiving such inputs, one or more outputs canbe projected, as described above with respect to step 1811. (It shouldbe understood that in the referenced implementations, the sequence withwhich steps 1812 and 1811 occur are preferably reversed, such thatinputs are received, and then outputs are projected based on suchinputs. However, as noted herein, the various steps, operations, etc.,that pertain to and/or make up any and all of the various systems andmethods described herein should not be understood to be required to beperformed in a particular order or sequence. Rather, such steps can bearranged and/or performed in any number of sequences, as can beappreciated by those of ordinary skill in the art, and each suchsequence/arrangement should be understood to be encompassed by themethods and systems disclosed herein).

By way of further example, it should be understood that in certainimplementations, the systems and methods disclosed herein can beconfigured such that one or more of the output(s) that the mobile devicegenerates/projects upon/in response to a user input are not readilyaudible to humans, though such output(s) are perceptible to otherelectronic devices (e.g., a device used by a teacher and/or in theclassroom, such as the teacher's mobile device and/or other devices suchas devices configured to perform and/or provide the same or similarfunctionality), in a manner known to those of ordinary skill in the art.In such scenarios, various devices, such as a device used by a teacher,can be configured to perceive and recognize the referenced output(s)(that is, those output(s) that are not readily audible to humans butwhich may be in the audible range and not audible by virtue of theirshort duration (temporal summation) and/or their low volume). Moreover,such device(s), such as a device used by a teacher or administrator, canbe configured to generate and/or project another signal, such as asignal that is readily audible to humans. In doing so, the teacherand/or others can be alerted (by way of a human-audible signal/tone) tothe fact that a mobile device is in use within the classroom. It can beappreciated that such an implementation can be advantageous in certainsituations because in utilizing signals that are not audible to humans,potential distractions arising as a result of periodic/ongoingprojection of audible noises (as emitted from chirp-enabled devices) arereduced. Moreover, it should be understood that in certainimplementations a device, such as a device used by a teacher, canconfigure other mobile devices (such as mobile devices belonging tostudents present in the teacher's classroom and/or students in theteacher's class) not to emit readily audible sounds during times whenthe teacher sanctions use of mobile devices for his/her students, suchas for legitimate learning purposes. It should also be noted thatvarious of the implementations described herein can also be configuredsuch that a mobile device, such as a mobile device belonging to astudent, generates/projects output(s) that are readily audible to human.

In certain implementations, the referenced chirp-enabled mobiledevice(s) (e.g., a device belonging to and/or being used by a student)can be configured to receive a special output (such as a signal, asdescribed herein) originating, for example, from another device, such asa device controlled and/or operated by a teacher. As referenced above,in certain implementations, such output/signal can either be readily ornot readily audible to humans, whereupon the mobile devices that receivesuch signal preferably cease to chirp (that is, to project/emit anoutput as described herein) when the user interacts with the device forsome period of time or until they receive another signal that theyshould re-initiate chirping when the user interacts with the device (itshould be noted that in other implementations the device can, bydefault, not be in chirp mode, or cannot be in chirp mode on account ofthe teacher disabling it, and chirp mode in such devices can besubsequently activated by the teacher, such as by projecting theappropriate signal to such devices). It should be noted that suchspecial signal is preferably secure so that it cannot be readily emittedby all devices (e.g., non-Teacher Devices so as to unintentionally ornefariously disable chirping on chirp-enabled mobile devices. Methods ofensuring this security are known to those of ordinary skill in the art.In certain implementations it can also be useful to utilize two-waycommunication, including various forms of “handshaking” between themobile device(s) and the “teacher's device,” in a manner known to thoseof ordinary skill in the art.

At step 1815, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, adjusts one or moreaspects of one or more outputs based on one or more of the inputs. Thatis, in certain implementations the various device(s) can be configuredwhereby a device chirps in response to one or more external stimuli(e.g., one or more sounds) in a manner that configures the device tochirp more or less frequently and/or more or less loudly. For example, ateacher that hears a chirp, but is unsure as to which device in theclassroom emitted the chirp, can use his/her a mobile device or adifferent electronic device, mechanical device and/or physiologicalaction (e.g., his/her voice or a hand clap) to emit a signal which, uponreceipt and processing by chirp enabled devices, causes such devices tochirp, either in their usual manner or in an alternative manner (e.g.,in a more frequent and/or a louder manner). Additionally, in certainimplementations, one or more aspects of the outputs/chirps can beadjusted based on various determinations, such as a determination thedevice is operating in a regular/normal fashion for an extended periodof time (indicating that the present use of the device is likelypermitted), as described in greater detail below.

At step 1820, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes the one ormore outputs and the one or more inputs. In doing so, a correlationbetween the one or more outputs and the one or more inputs can bedetermined. By way of illustration, in certain implementations a mobiledevice can be configured to chirp (that is, to generate/project anoutput), such as in response to a user's tactile input, such as a buttonpress or a tap/gesture at a touchscreen), and the mobile device can, inturn, receive/perceive such chirps by receiving them as inputs viamicrophone 145D. As such, a correlation can be computed, reflecting thedegree to which such outputs (that is, the chirps or signals projectedfrom speaker 146 of mobile device 105) correlate with the inputs (thatis, the sound of such chirps/signals) are, in turn, received bymicrophone 145D. It can be appreciated that if a strong/closecorrelation can be identified between such outputs/inputs, it is likelythat the mobile device is operating properly with respect to projectingand receiving chirp signals. However, if such a strong correlationcannot be determined, it can be determined that the mobile device mayhave been/has been tampered with, such as in order to prevent theprojection of chirp signals (e.g., if the user breaks and/or attempts tomuffle/mute speaker 146).

By way of further illustration, in certain implementations thepresence/absence of one or more input(s) and/or the presence/absence ofa correlation between a first input and a second input can bedetermined, while the device is within a defined geographic area and/orwithin a defined date/time window. That is, in certain arrangementsrestriction module 171 is configured such that one or more inputs (e.g.,depressing a button, interaction with the touchscreen, device movement,etc.) cause the outputting referenced above at step 1811. Thus, giventhat such inputs trigger the projecting of the referenced audio outputthrough speaker 146, it can be appreciated that microphone 145D can beeasily configured to have the capacity to detect such an output becausethe timing in which to look for the signals is exactly known to thedevice. Accordingly, if a presence of an audio output and/or a presenceof a correlation between a first input (e.g., a user depressing abutton) and a second input (e.g., detecting the audio output projectedby speaker 146 in response to the user's input at microphone 145D) isdetermined, the restriction scheme (that is a scheme requiring suchongoing ‘chirping’ in order to prevent covert operation of the mobiledevice) can be determined to be working properly, and no change oradjustment need be made (given that the restriction(s) are preferablyconfigured, in certain implementations, to allow the device 105, 160 tooperate in a conspicuous manner). However, if the presence of an audiooutput and/or the presence of a correlation between a first input (e.g.,a user depressing a button) and a second input (e.g., detecting theaudio output projected by speaker 146 in response to the user's input atmicrophone 145D) is not determined, the restriction scheme can bedetermined to be unlikely to be working properly. This malfunction can,in certain circumstances, be due to a user attempting to prevent mobiledevice 105, 160 from functioning properly, perhaps in hopes of avoidingthe referenced effects/restrictions. In such a case, where it has beendetermined that device 105, 160 is not operating properly, one or morerestrictions can be employed, modified, and/or removed. In doing so, theframework established can ensure that unauthorized use of the device105, 160 (e.g., during a class) is effectively precluded, except, incertain circumstances, such as in emergency situations. By way offurther illustration, it may be useful for the device to output sound(e.g., frequency, duration, volume) from its speakers and listen for iton its microphone, unrelated to the user's interaction with the device,and where such sounds are similar to the sounds that the teacher devicestransmit so that the device will not be blocked from receiving thesignals from the teacher's device if and when they are transmitted. Ifthe student device does not receive the signals so transmitted by thestudent device, i.e., the speaker and/or microphone are not workingproperly, the device will be restricted.

Moreover, in certain implementations, in response to such previouslydescribed external stimuli, only those devices that meet one or moreconditions (e.g., devices that have chirped within the last few minutes)are to chirp in response to one or more such external stimuli. Forexample, a teacher that hears a chirp, but is unsure as to which devicein the classroom chirped, can use a device or take an action to emit aoutput/signal which will cause chirp-enabled phones that meet thereferenced condition(s) to chirp in their usual or in an alternativemanner.

In certain implementations, the output/signal that the mobile deviceemits/projects upon user input can consist of two or more elements, atleast one of which is preferably audible. For example, thedetection/determination as to whether the device's speaker is workingproperly (as referenced herein) can be performed by having the deviceemit one or more outputs/signals, with or without connection to theuser's interactions with the device, that are not ready/easily audibleto humans (e.g., due to their frequency, intensity and/or duration), butwhich can also be perceived by microphone 145D (the “Detection Signal”),while another output/signal, which preferably enables teachers toidentify mobile devices that are in use (the “Teacher Signal”), can beat a frequency in the human audible range. It can be appreciated that byemitting/projecting the detection signal in a range or for durationsthat are not readily audible to humans, such a signal can optionally betransmitted louder, thus improving the signal to noise ratio (SNR),without distracting others.

Additionally, in certain implementations the Detection Signal and/or theTeacher Signal outputted/emitted from different mobile devices can varyacross different devices (it should be understood that in certain otherimplementations such signals/outputs can actually be the same signal).For example, such outputs can be randomized and/or altered by the userinput (e.g., different chirps correspond to different types of inputs,e.g., texting, game playing, etc.). This is useful as it can make thetask of detecting the chirp more accurate, easier, more power efficientand/or faster.

At step 1842, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, removesone or more previously employed restrictions, and/or maintains one ormore previously employed restrictions). That is, as referenced above, ina scenario where a close coordination can be identified between one ormore inputs and outputs, such a correlation can indicate that the‘chirp’ restriction is operating properly at the mobile device, and theemployment of such a restriction can be maintained. However, in ascenario where such a close correlation cannot be identified, thusindicating that the device may be malfunctioning and/or has beentampered with. In such a scenario, a further restriction can beemployed, such as a restriction deactivating all operation of thedevice. Finally, in implementations where the teacher's device (orsimilar) signals to the student's device to disable/enable chirp mode onthe student's device, the appropriate changes to the restrictions willbe made.

In certain implementations, the student devices can be restricted (e.g.,instead of being made conspicuous) as desired based on an instructionoriginating at a teacher device, i.e., the student device can be putinto ‘Class Mode,’ where one or more functionalities of the device arerestricted (e.g., all use is disabled except for emergency calls), whileTeacher Mode is on or for some period of time.

Turning now to FIG. 25, a flow diagram is described showing a routine2500 that illustrates a broad aspect of a method for selectivelyprojecting outputs at a mobile device 105 in accordance with at leastone embodiment disclosed herein.

At step 2510, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, receives one or moreinputs, substantially in the manner describe in detail above withrespect to step 1710. For example, such inputs can originate at theaccelerometer and/or gyroscope and/or user interface of the mobiledevice 105, and reflect the movement/motion perceived at the device.

At step 2520, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes theinput(s) to determine a first relationship (e.g., a correlation). By wayof example, inputs, such as those received at step 2510, can beprocessed, such as with one or more operation signatures. In doing so, arelationship between the inputs received and the operation signaturescan be determined.

By way of illustration, it should be understood that in certainimplementations, the ‘chirps’ referenced herein can be triggered basedon the movement of a mobile device, and/or a combination of user inputand movement. For example, inputs received from the accelerometer and/orgyroscope of a device (such as at step 2510) can be processed, such asby being processed with/against one or more operation signatures (thatis, data that identifies, such as based on mechanical and/or statisticalanalysis, how a device moves when engaged in certain activities, such aswhen a user is texting, walking, etc.). It can be appreciated that indoing so, the manner in which the device is being used can be determined(e.g., whether the device is being used to play a game, text, etc.),such as based on a correlation between the inputs and the operationsignature, For example, it can be appreciated that the signature ofvarious inputs originating at the various sensors when the device isbeing used to text, surf and/or play games is easily differentiable fromthe sensor signature of the device when the device is at rest and/orwhen the user is walking with the device on his/her person or in a bag,as is known to those of ordinary skill in the art.

At step 2522, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, projects one or moreoutputs based on the first relationship. For example, in a scenariowhere it has been determined (such as based on the relationship computedat step 2520) that the user is texting or playing a video game onhis/her mobile device, the device can be configured to project one ormore outputs (e.g., chirps), thereby creating a scenario whereby others(such as a teacher) can be made aware of such activity.

At step 2524, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes the one ormore outputs (such as those projected at step 2522) and one or moreinputs (such as an input received via a microphone, substantially in themanner described above with respect to step 1812). In doing so a secondrelationship, such as a correlation can be determined that reflects acorrelation between the one or more outputs and the one or more inputs,substantially in the manner described above with respect to step 1820.As described in detail above, it can be appreciated that in doing so, itcan be determined whether or not the speaker 146 of mobile device 105 isfunctioning properly (and thus is projecting outputs/chirps, such asthose projected at step 2522), or whether the speaker may have beentampered with, as described in detail above.

At step 2542, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, removesone or more previously employed restrictions, and/or maintains one ormore previously employed restrictions), preferably based on the secondcorrelation (as computed at step 2524), substantially in the mannerdescribed above with respect to step 1842.

Turning now to FIG. 26, a flow diagram is described showing a routine2600 that illustrates a broad aspect of a method for selectivelyconfiguring overt operation of a mobile device 105 in accordance with atleast one embodiment disclosed herein.

At step 2602, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, determines alocation of the mobile device and/or the current time/date. For example,using the GPS sensor of the mobile device, the location of the devicecan be determined. Specifically, in certain implementations, thelocation of the mobile device can be determined as being within adefined area or areas, such as within the grounds of a school, usingtechniques known as geofencing, as are known to those of ordinary skillin the art. In certain implementations, the presence of the device in anarea of interest (e.g., the school) can be detected/determined by thedevice by sensing the presence of the wifi signals associated with theschool's wifi transmitters and/or cell towers/base stations that areknown to be near the area of interest. By way of further illustration,the current time date can be determined from one or more sources (e.g.,the device's internal or remote clock/calendar, and/or a remote/thirdparty source such as the GPS time, the cellular time, the wifi networktime, etc.—i.e., sources that a user is potentially less likely to beable to tamper with).

At this juncture, it should be noted that in certain implementations,any or all of the following steps (2605-2642) can be employed based onthe determination at step 2602. Thus, by way of example, based on adetermination (at step 2602) that a mobile device is within a definedarea (e.g., a school) at a certain time (e.g., during school hours), arestriction can be employed at the device, as described with referenceto step 2605.

At step 2605, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs a firstrestriction at the mobile device. It should be understood that the firstrestriction preferably configures the mobile device to operate in anovert mode. It should be understood that the term “overt mode” as usedherein is intended to encompass one or more modes and/or operationalstates of a mobile device that configure the device to operate in such away such that operation of such a device by a user, on average, will bemore conspicuous to others in the vicinity/presence of the mobile devicethan if the device were not configured to operate in such a way. Anexample of such an overt mode is a restriction that configures thedevice to project an audible ‘chirp’ tone in response to every (or onlycertain) user input(s) received at the device, such as in the mannerdescribed in detail herein.

By way of further illustration, in certain implementations, an overtmode can include a restriction that restricts the mobile device toreceive one or more commands/actions/events (such as the command to senda message or email or open a message, and email editor, or a browser)only through voice commands. It can be appreciated that in doing so auser of the device will only be capable of sending a message by saying(or shouting) ‘send’ in an audible tone, thereby resulting in overtoperation of the device. It should be appreciated that such arestriction can be further employed together with/in parallel to otherrestrictions, such as restrictions requiring the user to perform one ormore tactile gestures (e.g., holding a finger on a region of atouchscreen while saying ‘send’).

By way of further illustration, in certain implementations, an overtmode can include a restriction that restricts the mobile device toreceive one or more commands/actions/events (such as the command to senda message or email or open a message, an email editor, or a browser)only based on a ‘shake’ gesture (that is, a gesture that can beidentified as an ongoing significant deviation from the typical inputsprovided by the accelerometer/gyroscope of a device). It can beappreciated that in doing so a user of the device will only be capableof sending a message by shaking his/her device, preferably vigorously,thereby resulting in overt operation of the device. In otherimplementations, similar gestures, such as large/broad movements of themobile device, can similarly result in overt operation of the device. Itshould be appreciated that such restrictions can be further employedtogether with/in parallel to other restrictions, such as restrictionsthat entail the simultaneous projection of one or more chirps/signals,as described herein.

At step 2610, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, receives one or morefirst inputs, substantially in the manner describe in detail above withrespect to step 1710. For example, such inputs can correspond to one ormore user interactions with the device, such as the user typing anemail, playing a game, etc.

At step 2620, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes theinput(s). In doing so, a determination can be computed that reflects anoperation state of the mobile device. By way of illustration, based onthe location within and/or the time/date during which the device isoperating (indicating whether the device is/is not within schoolgrounds, and/or whether the device is/is not operating during schoolhours) in addition to the inputs received (reflecting a particularoperation or action being performed at the mobile device), adetermination can be computed reflecting the operation state of themobile device (e.g., a video game is presently being played in anon-school location during school hours, and/or a text is being sent ina school location during recess hours).

At step 2642, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, removesone or more previously employed restrictions, and/or maintains one ormore previously employed restrictions), preferably based on thedetermination.

It should be noted that in certain implementations, the transmission ofsignals to and/or the routing of signals received from all or certainmobile devices within a geo-area (which can be detected, for example,using the device's GPS and/or the wifi and/or the cellular tower/basestation and/or location information provided from the cellular carriersuch as DOA, AOA, signal strength) and/or in a certain date/time range,that are not chirp-enabled (i.e., not configured to chirp on user input)(and/or restricted such as in the manner described with reference toFIG. 26, such as where movement and/or and audible voice is required),is restricted. For example, a school's wifi network can be configured sothat it only transmits to/from mobile devices that were known to thewifi network to be chirp-enabled (and/or restricted such as in themanner described with reference to FIG. 26, such as where movementand/or and audible voice is required), or which mobile devices were on apre-defined list (e.g., using MAC addresses for teacher devices). Inanother example, one or more cellular carriers would only transmit(voice, data etc.) to mobile devices that are on a school's premises(e.g., within a geo-area) and in their cellular networks, that wereknown to the cellular network to be chirp-enabled (and/or restrictedsuch as in the manner described with reference to FIG. 26, such as wheremovement and/or and audible voice is required) or which mobile deviceswere on a pre-defined list (e.g., MAC addresses or UDIDs for teacherdevices). In both cases there can be exceptions for certain usage (e.g.,emergency calls, emergency text-messages) whereby the aforementionednetworks will allow such communications to pass through.

The following represents a logical flow that reflects the basicoperations of various of the implementations disclosed herein, in amanner that can be appreciated by those of ordinary skill in the art.

If chirping application is installed on device If during school hours If(device sees school wifi | | device GPS shows in geo-fenced area | |device sees certain cell towers) Beep when user inputs If mic hearsbeeps Allow free use Else Restrict as per usage policy Else if GPS showsoutside geo-fenced area Allow free use Else if no GPS signal Assume ingeo-fenced area Else Allow free use

At this juncture, it should be noted in certain implementations, variousaspects of the outputs/chirps projected by the mobile device can bedetermined/dictated based upon various determinations that can becomputed in relation to such outputs/chirps and the device's usage. Forexample, it can be appreciated that a device that is being used activelyand/or continuously by a user is relatively less likely to be operatingin a manner that is improper. As such, upon determining that a device isso operating, the device can be configured to chirp in a differentmanner (e.g., by adjusting the frequency and/or pattern and/or volume ofthe outputs/chirps).

At this juncture it should also be noted that the referencedrestrictions (e.g., geographic area and/or date/time can be, andpreferably are, established by a third party, such as a schooladministrator or parent. It should also be noted that the requiredgeographic determinations can be achieved using GPS receiver 145C usingstandard geofencing approaches known to those of ordinary skill in theart. Additionally, in certain implementations, one or more third partiescan optionally override various of the restrictions referenced herein.For example, in a scenario where one (or more) of the sensors at amobile device is broken or malfunctioning, it can be appreciated thatvarious authentication approaches may no longer be possible. As aresult, one or more third parties (e.g., a parent, telecommunicationsprovider, etc.) can override such restrictions, in order to account forthe malfunctioning/broken sensor, and thus enable the user to usehis/her device in an unrestricted manner.

In certain implementations, inputs originating at the magnetometer of adevice can be used/processed in order to determine if the device is in aclassroom or not by comparing a magnetic map that is presently perceivedat a device, such as in its current location, to a database of magneticmaps, such as for a school (or any other such location), and/or a set ofrules that define the areas in which students are and are not permittedto use their devices. Based on a determination that the magnetic map ofthe current location of the device can be matched to the magnetic map ofa location in which students are allowed to use their mobile devices,the usage of the device can be allowed. However, based on adetermination that the magnetic map of the current location of thedevice cannot be matched to the magnetic map of a location in whichstudents are allowed to use their mobile devices, the usage of thedevice can be restricted.

It should also be noted that, in certain implementations, the set ofrules defining the allowed and disallowed location(s) may be differentfor different devices and may change over time (i.e., based upon the dayand/or the time of day) and that the magnetic map database may residelocally, i.e., on the device itself, or remotely.

Moreover, in certain implementations, by (a) applying only to a devicethat is determined to be present on school grounds and/or during theschool day, and/or (b) applying to a device that is determined to be ina restricted device usage area, e.g., within a classroom (or at least isnot determined to be within a permitted area, e.g., a lunchroom), suchrestriction(d) can still be bypassed based upon whether and for as longas a teacher has configured the mobile devices in the classroom to allowfor their usage, such as in a manner similar to the one in which ateacher may configure devices in the classroom to temporarily not emitsounds as described herein.

It should be noted that whenever there is a signal (audible orinaudible) sent to or from a student device, such signal can also betransmitted via Bluetooth and/or WiFi.

It should also be noted that many of the techniques described hereinwith regard to reducing the power consumption on the device can apply tothe school/classroom setting as well where, in certain implementations,the various sensors of the device and/or other techniques are utilizedto determine whether or not the device is on school grounds.

It can be appreciated that people who make noise during movies distractthose around them. Mobile devices are a huge source of such unwantednoise.

Accordingly, in one implementation, devices in a theater hall can beconfigured to be selectively restricted while a movie is playing(optionally including its preview and trailers), but without restrictingsuch devices if they are outside the theater hall (e.g., at the popcornstand, in the bathroom, in the lobby, etc.).

In order to selectively restrict such devices by detecting that they arewithin a theater hall (e.g., during a movie screening), themicrophone(s) of the device can capture(s) and/or pass(es) audiorecordings (of some length, frequency, duty cycle, codec, format, filteretc.), such as to a remote server. Such recordings can be processed inorder to detect/determine whether the device is in the presence of ascreening/movie, such as by identifying sounds associated with aparticular movie (such as in the manner performed by Shazam for music),and/or by identifying sounds/patterns that are common to movies (orother media/events) in general. The identity of the particular moviebeing played can be identified and compared, for example, to a list ofcurrently running movies, such as in order to distinguish it from anolder movie (which may be relatively less likely to be screened within apublic theater).

This accuracy of such a technique can be improved by selectivelyemploying such techniques if the location of the device (e.g., asdetermined by its GPS, aGPS, BT, last known GPS, etc.) is firstdetermined to be in or near a movie theater. One way in this can beachieved is to use the GPS, if available, or alternative methods (celltower, wifi, BT), and/or using the last known GPS location.

It should be noted that while the user may cover the microphone of adevice, such as in an attempt to reduce the efficacy of thiscontext-detection technique, the device user will also not be able toeffectively engage in a voice conversation (the largest distracted moviewatcher problem) with a blocked microphone. It should also be noted thatthese techniques can also be employed in similar settings, such as wherepre-recorded audio is played and/or in settings where known live audiois played, e.g., classical theater, music concerts, speeches (with knowntext), etc.

In other implementations, a movie attendee who has exited (temporarilyor permanently) the theater in which a movie is being screened (e.g., tobuy popcorn) and whose device is still in “movie mode” (i.e., is stillselectively restricted), can provide a ‘self-declaration’ of thedevice/user being outside of the theater (e.g., using tactile, audioand/or visual input methods, such as those described herein), and, indoing so, can cause the movie detection mechanism to immediately (orrelatively more quickly) acquire sensor information and/or otherinformation to determine whether or not the device is still within moviecontext, in a manner that is relatively more expedient than would haveordinarily occurred. Such techniques can be particularly advantageous incases where, on account of power savings, the various data/informationacquired to determine whether or not the user is still viewing a movieare acquired with latency (e.g., with delay, in duty cycles, etc.)and/or at less than the fastest sampling rates possible. Accordingly,acquiring such data relatively more quickly (e.g., by triggering suchacquisition via the referenced ‘self-declaration’) can enable the deviceof a movie goer who exited a theater to have such a selectiverestriction lifted faster/sooner. Phrased differently, this techniquecan allow power-saving techniques to be applied more readily whilereducing the degradation to the user experience.

In other implementations, this problem can be solved (client-side only,server-side only or a combination thereof) by utilizing the digitalaudio watermarks/coded anti-piracy mark embedded within theater films(or inserting a similar or different mark into the film if such is notpresent within theater films or are otherwise ineffective for suchpurpose due to their frequency or other reasons) and such clientdevice(s) can be configured to be selectively restricted when (and foras long as) such mark is heard.

Moreover, in theaters within which sufficient network access (such as tocellular networks) is not present for such devices to properly utilizethe techniques described herein, such theater complexes can install oneor more access points as needed to facilitate such access. Moreover, theBSSIDs of these access points can provide additional locationinformation to geo-locate the devices within the theater complex (e.g.,inside a theatre, outside a theatre, etc.).

In other implementations, a hardware device can be installed within eachthe theater to be protected. While a movie is playing, such a device cancontinuously (and/or periodically) emit audio signals (inaudible,effectively inaudible and/or non-distracting) that can be perceived,recognized and/or interpreted by an appropriately equipped device toindicate presence within a movie theater having a live movie playing.Such a signal can be emitted at a frequency and/or at a volume that canprevent it from (and/or mitigate the likelihood of its) being heardoutside the theater. In another implementation, such signals can betransmitted over the in-theater sound system.

In another implementation, upon determining that the device microphoneis being blocked (when in or near a theater) so that the device does nothear the signal(s) necessary for it to identify that it is presentwithin a theater (e.g., the watermark, the special inaudible signal,etc., as described herein), such a device can be restricted or otherwisedisabled. For example, the device-based system can default to operatingbased on an assumption that the device is present in a movie, such as inthe same or similar ways described herein with respect to variousclassroom implementations.

In implementations with respect to which such watermarks or specialsignal devices may interfere with routine usage of a device in otherplaces/contexts (despite employing optional countermeasures that mayalso require positive geo-location data to determine that the device iswithin a theater in order to employ restrictions), thereby causing suchdevices to operate based on the assumption that they are present withina movie when they are actually not, the referenced in-theater signalscan be randomized and/or varied and/or crowd-sourced so that they couldnot abused. Various additional methods for securely delivering suchsignals are also contemplated, as known to those of ordinary skill inthe art.

It should be understood, with regard to any and all of theimplementations described herein, that while various of theimplementations have been described herein as being implemented by amobile device (for example, employing a restriction at a mobile device),it should be understood that any and all such embodiments can besimilarly implemented in relation to such a mobile device, such as, forexample, in a scenario where such a restriction is initiated/employed bya third party device such as a central machine that is capable ofcommunication with the mobile device. As such, all references providedherein that refer to a particular operation occurring at a mobile device(e.g., preventing a mobile device from a particular operation) should beunderstood to also encompass operations performed by an external/remotedevice which, in turn, can affect the operation of the mobile device(whether directly or indirectly), and all such implementations areequally within the scope of the methods and systems described herein.

Additionally, in certain implementations a communications provider(e.g., a cellular carrier) can optionally restrict the usage a device,such as the device operated by a driver of a moving vehicle. This can beachieved by determining if the device is in a moving vehicle and, if so,assuming that the device is a driver's (and restricting it accordingly),unless the device user has authenticated himself/herself as a passenger,as described herein.

In one implementation, a cellular carrier can determine whether thedevice is in a moving vehicle by analyzing successive location positionsof the device (as can be determined by cellular networks), pursuant,among other things, to government regulations/guidelines that requiresuch networks to be able to determine the location of a cellular device(such as in the case of an emergency), using such location positioningtechniques known to those of ordinary skill in the art, including butnot limited to methods for locating the device such as angle of arrival(AOA), time difference of arrival (TDOA), signal strength (device orcell-tower) and others.

In other implementations, a system/device can be configured toadaptively learn, over time, the context (e.g., moving in vehicle,stationary, etc.) within which a device is present upon receiving (or inthe absence of receiving) one or more data signals (e.g., pertaining toWiFi APs, cell-towers, locations or geo-areas, Bluetooth devices,accelerometer signals [e.g., corresponding to walking], etc.) and canthen determine the context of the device, alone or in conjunction withother data, upon subsequently receiving (or in the absence of receiving)one or more of such data signals, such as in the future.

For example, if, over the course of a sufficiently long and/orsufficiently recent period of time, it was determined that 98% of thetime a device was in range of a particular WiFi access point it was alsodetermined to be present within a moving vehicle, then it can be furtherdetermined that, upon subsequently determining that the device ispresent within range of that same WiFi access point (and, in certainimplementations, unless some other data, input, and/or indication to thecontrary has been received), the device can be determined to be presentwithin a moving vehicle.

For example, if, over the course of a sufficiently long and/orsufficiently recent period of time, it was determined that 98% of thetime a device was in range of a particular WiFi access point and didn'treceive a GPS signal (e.g., present deep inside a building) it wasdetermined not to be present within a moving vehicle, then it canfurther determined that, upon subsequently determining that the deviceis present within range of that same WiFi access point and not receivinga GPS signal (and, in certain implementations, unless some other data,input, and/or indication to the contrary has been received), the devicecan be determined not to be present within a moving vehicle.

It should be understood that, in certain implementations, the referenceddata can be maintained on a device-by-device basis (or user-by-userbasis) and/or aggregated across users (whether non-selectively, or,alternatively, selectively chosen in some manner, e.g., users withsimilar daily routines, users with similar home or work locations, etc.)such as using one or more ‘crowd-sourcing’ approaches/techniques, suchas in a manner known to those of ordinary skill in the art.

In another implementation, the cellular carrier/operator can receivelocation and/or speed information from the device itself, consisting ofGPS information and/or information from the one or more of the device'ssensors. For example, the cellular carrier can send requests to thedevice's SIM card to query the device's GPS and pass such informationback to the carrier. In another example, the carrier can requestinformation from a process running on the device which can obtain suchinformation from the GPS and/or the device's sensors. If no such processis running on the device (and/or if such a process cannot beinitialized), the carrier can identify such device to be a driver deviceand can further apply the associated restrictions, as described herein.The effectiveness of this method can be increased if the process and/orthe information coming from the process is authenticated and/orverified, so as to prevent the transmission of erroneous informationthat might otherwise trick a cellular carrier into thinking that thedevice is not in a moving vehicle. Such authentication and/orverification can be done in several ways, for example: (a) The GPSvalues sent from the device can be compared with those obtained directlyby the carrier network. If the carrier network is clearly showing thatthe device is moving, yet the data the device is passing to the carriershows otherwise, this can indicate a security problem; (b) the devicecan pass an authentication code to the carrier in a manner known tothose of ordinary skill in the art.

Additionally, in order to more accurately and/or more quickly and/ormore efficiently determine if the device is in a moving vehicle, thecarrier can combine location/speed information sourced from the carriernetwork with the information sourced from the from the device.

Upon receipt of such device location/speed information, the carrier candetermine whether the device is in a moving vehicle. In oneimplementation, if the speed of the device is greater than a certainthreshold speed, it is determined to be in a moving vehicle.

Upon determining that a device is in a moving vehicle and until suchtime that it is determined that such device is no longer in a movingvehicle, the carrier can restrict (partially or completely) theinformation that is sent to/from such device unless the device's userhas authenticated the device as a passenger device using, among others,any one of the passenger authentication methods described herein. Theeffectiveness of this method can be increased by ensuring that anypassenger authentication is trustworthy, so as to prevent thetransmission of erroneous information in order to trick a cellularcarrier into thinking that the device is being used by a passenger. Thiscan be done, for example, by authenticating the passenger authenticationinformation, using methods known to those of ordinary skill in the art.

Additionally, the cellular carrier can strengthen any such restrictionsby instructing the device's SIM and/or code running on the device itselfto further restrict the device (e.g., preventing wifi communication).

Moreover, various security measures can be employed to ensure that thedevice user does not trick the cellular carrier into providing data tothe device while the user is the driver. As example, a device that hasbeen ‘rooted’ or ‘jail-broken’ may not be allowed to authenticate as apassenger. As an additional example, various security options forcentrally (e.g., from a cellular data center) authenticating applicationdata sent from a mobile device can be employed, such as, (a) creatingnon-repeating data by incorporating in-data timestamps to make it harderto ‘replay’ data; (b) using a digital signature to sign data on thedevice before it is sent to the carrier, where a one-time key generationtime process can be employed to make this method even harder tohack/override; (c) performing such authentication at the operatingsystem level (e.g., within the kernel) to make it harder to replace thetrusted data with altered data; and/or (d) performing the authenticationat the hardware level. These techniques and similar ones are known tothose of ordinary skill in the art of computer security andcryptography.

It should also be noted that, in certain implementations, some or all ofthe various techniques and technologies described herein can beincorporated entirely or in part into the operating system of a device.In doing so, various operations can be relatively less susceptible touser interference/intervention, and also make the processes executingwith respect to the various techniques relatively more stable and/ormore energy efficient.

It should be noted that in some methods of passenger authentication (forexample, passenger authentication methods that incorporate a repeatedpass-phrase, pass-code and/or pass-action), the effectiveness of suchmethods can be increased by incorporating a protocol that furtherenhances security, by (a) running at least one component process of thepassenger authenticating process on the device in a manner that allowssuch component process to be authenticated against a central serverusing a pre-assigned private key that signs OS information about suchcomponents and/or other components by using a signed kernel module; (b)if the component process authentication succeeds, by having a centralserver send a phrase, code and/or action to the passenger authenticatingprocess on the device which, in turn, displays such phrase, code and/oraction to the user; and (c) sending the phrase, code and/or actioninput/performed by the user back to a central server, whereupon thecentral server only authenticates the device user as a passenger if thephrase, code and/or actions match those that were sent and are performedin a timely manner.

It can also be appreciated that it can be advantageous to intelligentlymanage use of energy/power at a mobile device, such as in any or all ofthe various contexts and settings described herein. Due in part to theirsmall size, mobile devices have energy constraints (e.g., limitedbattery power). Accordingly, it can be advantageous to identify andcontrol processes running on mobile devices that use energyunwisely/sub-optimally. Moreover, because mobile devices are nomadic,they are easily misplaced. Such misplacement, among other things,presents a security threat.

Accordingly, in certain implementations a context in which a deviceoperates (e.g., one or more of: moving, moving in a vehicle, moving in aparticular type of vehicle [e.g., bicycle, car, truck, bus, airplane],connected to a power source, battery state, user presence [as can bedetermined, for example, by screen state (on/off), lock screen state(on/off), keystrokes, button presses, camera, audio, proximity, heat,etc.], prompting the user to determine if the user believes that thecontext is such that the use of one or more device resources should bechanged, etc.) can be determined. Based upon the determined context(s),one or more resources used by one or more processes on the device can beadjusted (e.g., processes that use screen display, wake locks, sensorcalls, camera, speakers, microphone, RF, wifi, data communication,etc.), such as based on the determined context, thereby providingvarious benefits (e.g., energy savings, increased security, betterand/or more accurate information/determinations, etc.).

FIG. 33 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3305 an operational state of a firstsensor of a device can be determined. At 3310, an operational state of asecond sensor of the device can be selectively adjusted, such as basedon the operational state of the first sensor.

FIG. 34 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3405 a power connection status of adevice can be determined. At 3410, an operational state of a sensor ofthe device can be selectively adjusted, such as based on the powerconnection status.

In certain implementations, inputs originating at one or more of thesensors of a device (including but not limited to GPS, RF, Wifi, NFC,BT, accelerometer, gyroscope, camera, microphone, magnetometer, lightmeter, proximity sensor, temperature sensor, compass, keyboard, buttons,etc.) can be used/processed to determine if the device is moving and/orwhere the device is located. If it is determined that the device is notmoving for more than a certain period of time (e.g., 5 minutes),applications that are employing a ‘wake lock’ (e.g., a screen wake lock,a CPU wake lock, a GPS wake lock) can be cancelled and/or modified. Forexample, many navigation applications (e.g., Waze) that run on mobiledevices use wake locks to override the screen lock settings of thedevice in order to keep such applications continuously visible to thedevice user. Such wake locks are often static, i.e., for as long as theapplication is running (e.g., in the foreground), the wake lockpersists. Accordingly, upon determining that the device is not movingfor some period of time (e.g., no significant GPS changes for 5minutes), a wake lock of such applications can be overridden (therebyenabling the lock to be disabled). Such techniques can be particularlyapplicable with respect to applications or processes that alreadyacquire and/or use location based information and/or movement basedinformation because little to no or additional energy expenditure islikely to be required to employ the operations disclosed herein.Moreover, such context-based resource management determinations andoperations can also enable certain security benefits. For example, in ascenario where a device was running a navigation application (e.g., onethat implements a screen/CPU wake lock) and the user forgot the devicesomewhere (e.g., in a vehicle, in a restaurant, etc.), the screen of thedevice will not lock (on account of the screen/CPU wake lock whichcontinues to be employed), thereby allowing anyone who finds the deviceto easily access the information on the device. By adjusting the deviceresource usage (in this example, the screen usage of the device as aresult of its wake lock) based upon its context, it can be determinedthat this device was not moving and its wake lock can be overridden,thereby preventing access (or further access) to the device by unwantedpersons.

In another implementation, a wake lock can be controlled dynamicallybased upon the location of the device as determined by inputsoriginating at one or more of its sensors in conjunction with and/orseparate from the movement of the device as also determined based oninputs originating at one or more sensors. For example, if the device isdetermined not to have moved for some period of time, but is determinedto be within a certain distance of a specific location (e.g., the homeor office of a user), the wake lock can be overridden according to onerule (e.g., wait a relatively longer time before overriding the wakelock is), whereas if the device is not determined to be near such alocation, the wake lock can be overridden according to a second, morestringent rule (e.g., wait a relatively shorter time before overridingthe wake lock).

It should also be noted that overriding a wake lock can be implementedin various forms (e.g., canceling the wake lock altogether, changing thetype of wake lock (e.g., from a bright wake lock to a dim wake lock),and/or canceling the wake lock and taking an action like dimming thescreen).

It should also be noted that the ability to control device resources(e.g., by controlling wake locks) based upon their device's context(e.g., by determining if the device is moving and/or it location) so asto reduce energy expenditure and/or improve security can also enable theimplementation of processes and/or applications that have heretofore notapplied certain resource intensive techniques (e.g., wave locks, sensorsampling) because of the referenced energy consumption and securityconcerns, thereby enabling responsible/sustainable employment of suchresource intensive techniques and, in so doing, allow their users accessto better and/or more accurate information and a better user experience.

In certain implementations, if a device is determined to be oriented ina ‘flat’ orientation (e.g., resting on a table, as can be determined,for example, based on one or more accelerometer inputs) and also ‘upsidedown’ (i.e., with the screen of the device facing downwards, such astowards the table, which can also be detected one or more accelerometerinputs), then it can be determined that the user is unlikely to belooking at the screen of the device. Accordingly, based on such adetermination (and, in order to save power), the display/screen of thedevice can be turned off/dimmed, or otherwise deactivated, even beforethe device's ordinary screen timeout would have otherwise turned it off.Such a state/status with respect to the display/screen can be maintaineduntil, for example (i) the screen is activated (such as upon receipt ofan input, button press, etc.), (ii) the orientation of the device isdetermined to have changed so that it is relatively more likely that theuser is using (or may wish to be using) the screen, and/or (iii) theorientation of the device is determined to have changed (as in (ii))within a certain period of time, otherwise the screen can remaindeactivated (despite orientation changes) until the screen isaffirmatively activated (as in (i)).

In another implementation one or more of the sensors that are used byany of the processes running on the device can be controlled dynamicallybased upon the device's context. For example, the accelerometer of thedevice can be used to determine that the device is not moving, and, as aresult, a process that uses the (much higher energy expenditure) GPS canbe stopped and/or the rate at which such process uses the GPS can beslowed (in certain implementations, even to zero). Such dynamic controlof sensors can be affected in various ways. For example, from within aparticular process itself (in the GPS example, the process using the GPScan register to receive GPS information less frequently), through themechanism that controls the sensor readings and/or the distribution ofthe information therefrom (in the GPS example, the device can beconfigured to acquire GPS information relatively less frequently).

In another implementation, power connection state, status, and/orcontext of a device can be determined, i.e., whether or not the deviceis connected to a power source. If it is determined not to be, processesrunning on the device can be notified accordingly and can selectivelyreduce the resources that they are using. If the device is determined tobe connected to a power source, the processes running on the device canalso be so notified and can selectively increase the resources that theyare using. Determination of the context can be further refined by alsotaking into account the level of charge of the device's battery. Forexample, if the device is not connected to power, but its battery isfully charged, it can be reasonable for processes to use resources moreaggressively, whereas if the battery not fully charged, processes can beconfigured to lower their use of power intensive resources.

It should also be noted that the context determination(s) describedherein can be implemented within an application/process and/or byanother process on the device (e.g., a user process, a system process)which distributes or makes available such context information to otherprocesses, such as those running on the same device (e.g., via an API).Moreover, parts and/or aspects of the context determination(s) can alsooccur in locations that are external to the device (e.g., one or morenearby mobile devices, other computers, one or more remote computers,etc.).

It should also be noted that many or all of the determinations and/orother operations referenced and/or described herein can be useful (andtherefore provided) to other applications or processes running on thesame device (and/or external to the device) so that multipleapplications do not need to perform the same or similar determinations.Such determination(s) can be provided to such applications or processes(e.g., through an API). For example, a navigation application that wantsto prevent a driver from the distraction of inputting a destinationwhile driving but wants to permit a passenger to do so, can beconfigured to query the application's API as to whether the device is(a) in a trip and/or (b) is being operated by a driver or a passenger.

Many of the techniques described and/or referenced herein can have oneor more components that differ for specific devices, such as based uponpreviously observed behavior of that device and/or that of a userassociated with the device and/or an environment/context associated withthe device. For example, the angles at which a device is held/oriented(such as those consistent with operation by a driver or a passenger) canbe “learned,” (e.g., using machine learning techniques are known tothose of ordinary skill in the art), the speed at which a user types andthe consistency of such speed (as a driver and/or as a passenger) can belearned, the characteristics/patterns with which a device moves/shakeswhen used by a user can be learned, or practically anything that happensrepeatedly, so as to better fit a set of rules to differentiate the roleof a user explicitly (e.g., in-vehicle role, ability to perform a task)or implicitly (e.g., from the location of user) for each particular usercan be learned.

These one or more varying components can also be classified based uponthe different contexts of each user, e.g., when a user is a driver andwhen the user is a passenger using various techniques (e.g., trainedlearning and/or untrained learning, clustering) as are known to those ofordinary skill in the art.

In certain implementations a mobile device operated by a bicyclist (oranother vulnerable road user like a pedestrian, skateboarder,roller-blader, runner etc.) can transmit the real-time location of thedevice to a remote server.

Moreover, in certain implementations a mobile device determined to beused within a vehicle (e.g., a car, truck, bus, train) by a userdetermined to be driver (or passenger) can transmits the real-timelocation of the device to a remote server (e.g., as is done incrowd-sourced ‘SatNav’ applications like Waze).

Moreover, in certain implementations an application can determine (and,optionally transmits to a remote sever) the mode of transportationdetermined (e.g., bicycle, car, etc.), such as with respect to the userof the device. In certain implementations, such determination(s) can bemade in a relatively passive manner, e.g., based on the device's sensors(e.g., the accelerometer and/or gyroscope readings, changes andvariability thereto and the spectral frequencies thereof). For example,bicycles are always falling and being corrected, whereas most othervehicles are generally balanced on the ground. This distinction can bemade using the device's sensors (e.g., accelerometers, gyroscope,magnetometer, etc.). By way of further example, a transportation modecan be determined based on the determined speed (e.g., based on GPS),such as with respect to the change in speed between portions of the roadhaving different gradients (as most vehicles other than bicycles haverelatively lower sensitivity to gradient and/or gradient changes). Byway of further example, a transportation mode can be determined based onchanges of angle in turns (as bicycles angle into turns whilefour-wheeled vehicles do so much less). By way of further example, atransportation mode can be determined based on the spectral frequenciesmeasured/determined by the sensors of a device, as those determined withrespect to a bicycle are relatively different than those of the sensorsof a device being used in a car. By way of further illustration, atransportation mode can be determined relatively actively, such as byprompting a user to identify (e.g., with voice, touch, haptic, etc.inputs) the mode of transportation being used, such as prior to thestart of (or during) a trip, and/or by virtue of the fact that theinformation provided in this system can be packaged differently fordifferent use cases (e.g., bicycles vs. drivers) and the transportationmode of the device user can be determined from the application used.

In certain implementations a driver or a cyclist can elect to receivealerts (such as real-time alerts) to their device based on a particularof transportation type, mode, or class. For example, cyclists can selectto receive alerts of approaching motor vehicles and motor vehicledrivers can select to receive alerts of nearing cyclists. Such alertscan be delivered to the user by the device visually (e.g., on screen),audibly (device makes a distinctive noise) and/or hapticly (devicevibrates in some way, e.g., that may be user configurable and can evenbe integrated into the transportation equipment, e.g., device causesuser handlebars to vibrate, device causes the steering wheel to vibrate,etc.).

FIG. 38 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3805 one or more inputs can bereceived, such as in relation to a user device. At 3810, the one or moreinputs can be processed, such as in order to determine a transportationtype associated with the user device. At 3815, the transportation typecan be processed, such as in relation to one or more aspects associatedwith one or more other devices. In certain implementations, thetransportation type can be processed in order to generate one or morenotifications, such as with respect to at least one of (a) the userdevice or (b) at least one of the one or more devices. In certainimplementations, the transportation type can be processed in relation toa visibility condition state. Moreover, in certain implementations thetransportation type can be processed in order to generate one or morenotifications, such as with respect to the visibility condition state.At 3820, the one or more notifications can be provided, such as to atleast one of (a) the user device or (b) at least one of the one or moredevices.

FIG. 39 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3905 one or more inputs can bereceived, such as in relation to a user device. At 3910, the one or moreinputs can be processed, such as in order to determine a transportationtype, such as a transportation type associated with the user device. At3915, the transportation type can be processed, such as in relation toone or more data items associated with the transportation type.Moreover, in certain implementations the transportation type can beprocessed in order to generate one or more notifications pertaining tothe transportation type. At 3920 the one or more notifications can beprovided, such as in relation to the user device.

Moreover, in certain implementations the referenced alerts can befiltered to be operative/employed only in certain areas and/orsituations and/or conditions, such as based upon the selection of thedevice and/or the device user's supervisors (e.g., parents, employeretc.). For example, a cyclist might choose to receive alerts of nearbymotor vehicles (a) when she is not near a city, (b) when a particularvehicle is determined to be exhibiting dangerous behavior (e.g., drivingabove a certain absolute speed, driving above a speed relative to theallowed speed on the current road (e.g., a vehicle travelling more than20 MPH above the speed limit), swerving, is determined to be a dangerousvehicle based on its current drive or from historical information,etc.), and/or (c) when the road conditions are determined to bedangerous/unsafe (e.g., poor visibility due to weather, night, windyroad etc.). In another example, a driver can choose to filter out alertsfor nearby bicycles where (a) the bicycle is on the opposite side of theroad of the driver's vehicle (e.g., as can be detected/determined by theGPS in one and/or successive readings, by the accelerometer and the roadangle (a bicycle climbing on one side of the road and a bicycledescending on the opposite side of the road have different accelerometerreadings when fixed to the bicycle with known orientation) and/or (b)the bicycle is determined to be on the sidewalk (e.g., as can bedetected from GPS and/or successive GPS readings, from the accelerometerreadings as a bicycle riding on the sidewalk approaches and leaves someintersections when the bicycle has to come down from sidewalk andre-elevate to the curbside).

Moreover, various aspects of the information learned/determinations madeby/in relation to the various techniques described herein can beincorporated into SatNav (satellite navigation) applications, such asthose that provide real-time or near real-time alerts to users (e.g.,Waze), such as with respect to road conditions or other information.

Additionally, in certain implementations information relating to thetransportation mode, such as of the vehicle within which a device ispresent/operating, can be generated/provided. For example, device userswho are determined to be riding bicycles can be provided information onthe nearest bicycle stores (e.g., for repairs), the nearest restaurants(to fuel up), the relevant recommended cyclist spots (e.g., good climbs,good off-roads), etc.

In certain implementations, information pertaining to pedestrians can beprovided, for example at crosswalks, where such users can be providedwith alerts to approaching vehicles. Moreover, in certainimplementations drivers can be alerted to pedestrians nearby to (e.g.,in or approaching) a crosswalk area.

It should be noted that while several of the techniques described hereinpertain to allowing vehicles and vulnerable road users to betterco-exist, many of these techniques can also be implemented in order toimprove the co-existence of vehicles with other vehicles or vulnerableusers with other vulnerable users. For example, it can be advantageousfor vehicle drivers to be aware of/alerted to other vehicles that areapproaching/nearing them, such as in situations of poor visibility(e.g., a blind corner or a blind turn, poor visibility conditions likesnow, fog, exiting a “hidden driveway,” etc.). By way of furtherexample, a vulnerable road user (e.g., a runner) can be alerted whenanother vulnerable user (e.g., a cyclist) is approaching, such as frombehind.

Moreover, while the techniques described herein can be employed insettings in which information is delivered with the involvement of aremote server, any or all of the described operations can also beimplemented directly between respective devices (e.g., the bicyclist'sdevice can communicate directly with the driver's device, rather thanthrough a remote server).

Additionally, such techniques can also be employed with respect to afixed device on the vehicle side (e.g., a vehicle infotainment system,an OBDII system) and/or the bicycle side (e.g., a bicycle computer).Moreover, such a fixed device can provide redundant and/or additionalsources of information (e.g., speed) or improved alerts (e.g., via alarger screen, louder speakers, more consistent remote communication,etc.) that can be used to augment (e.g., via increased accuracy and/orfunctionality), confirm (e.g., via increased accuracy) or replace (e.g.,with respect to lower latency and/or power consumption considerations)information otherwise obtained from and/or or determined with respect toa nomadic device (e.g., a portable device such as a smartphone).

It can be appreciated that various SatNav applications (e.g., Waze)provide alerts that are positionally fixed/static (e.g., that a car isstuck on the roadside in location X). Such alerts are either passed toall users or passed to users when they are near the location of thealert. As such, described herein in various implementations are alertsthat are positionally dynamic, i.e., alerts to items/occurrences whoseposition is changing (e.g., a bicycle rider, a wide vehicle, a slowvehicle, etc.). In addition, such dynamic position alerts can beprovided by the alertee.

Moreover, various navigation applications (e.g., Waze) include featureswhereby the locations of various other users can be presented(anonymously or not) to a particular user. Accordingly, usingdetection/determination techniques such as those described herein and(optionally) further incorporating the ability of a user toself-identify his/her mode of transportation, technologies describedherein can be configured, such as in conjunction with a navigationapplication, to show/indicate/provide alert(s) to the user as to themode of transportation of other users, whether in total (i.e., showingall modes of transportation for all displayed users), or selectively(e.g., showing/alerting a user only to vulnerable users, e.g., bicycles,pedestrians, etc., that are coming close, showing/alerting a user onlyto large trucks that are nearby, etc.).

Many of the techniques described herein with respect to reducing thepower consumption on the device can be apply to the bicycle/vulnerableroad techniques described herein, where, in certain implementations, oneor more sensors and/or other methods can be utilized in order todetermine whether or not a vehicle (within which a device ispresent/operating) is within a trip, and/or the mode of transportationused in such trip (e.g., bicycle, walking, rollerblades etc.).

It should also be noted that, in certain implementations, games and/orgame-related features can be incorporated into one or more of thetechnologies described herein. For example, in certain implementations,‘points’ or ‘credits’ can be awarded to a user who initiates theexecution of a determination/verification application (e.g., an ‘app’capable of determining whether a device user is likely to be a driver ora passenger). In other implementations, such ‘points’ or ‘credits’ canbe awarded to a user who successfully authenticates as a passenger,and/or such ‘points’ or ‘credits’ can be deducted from a user who failsto authenticate.

In certain implementations, it can be advantageous, such as in relationto a navigation application, to notify a user when the route that isusually optimal from their current location to their current destination(as is determined by navigation applications that implement dynamicrouting, such as Waze, as well as those using static routing), isdetermined to be sub-optimal, such as on a temporary basis (e.g., due toroad work, heavy traffic, etc.). It should be understood that thereferenced ‘current destination’ of the user can be determined, forexample, based on a user input (e.g., audio, touch, visual [e.g.,gestures], etc., inputs) into the navigation application, and/or can bedetermined (or “learned”), such as based on historical routes taken bysuch user (which can be accounted for based on the days of the weekand/or the different times of day during which such routes aredetermined to be traveled, for example).

FIG. 40 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4005 one or more navigationinstructions can be computed or received, such as between a firstlocation and a second location. At 4010, the one or more navigationinstructions can be processed, such as in relation to at least one of(a) one or more previously computed navigation instructions between thefirst location and the second location or (b) one or more previouslytraveled routes between the first location and the second location. Itshould be understood that, in certain implementations the referencedlocations (e.g., the first location and/or the second location) can bepractically any points along a navigation route (that is, notnecessarily the origin or destination of a parituclar trip). In certainimplementations, the one or more navigation instructions can beprocessed in order to determine one or more disparities, such as betweenthe one or more navigation instructions and the at least one of (a) oneor more previously computed navigation instructions between the firstlocation and the second location or (b) a previously traveled routebetween the first location and the second location. At 4015, one or morenotifications can be generated, such as based on the one or moredisparities. In certain implementations, the one or more notificationscan include one or more navigation instructions that characterize anaspect of the navigation between the first location and the secondlocation in relation to the at least one of (a) one or more previouslycomputed navigation instructions between the first location and thesecond location or (b) a previously traveled route between the firstlocation and the second location. Moreover, in certain implementations,the one or more notifications can include one or more navigationinstructions that characterize an aspect of the navigation between thefirst location and the second location as an instruction to deviate fromat least one aspect of the at least one of (a) one or more previouslycomputed navigation instructions between the first location and thesecond location, (b) a previously traveled route between the firstlocation and the second location, or (c) one or more frequently traveledroutes between the first location and the second location.

Moreover, in certain implementations the referenced notifications caninclude various navigation instructions that characterize an aspect ofthe navigation between the first location and the second location as aninstruction to continue performing at least one of the one or morenavigation instructions that were previously provided, such as isdescribed herein. Additionally, in certain implementations thereferenced navigation instructions (that are included in the referencednotification) can be those instructions that were previously providedduring the same trip as the navigation instructions received at 4005(e.g., an instruction that repeats a previously providedinstruction/instructs the user to continue performing a previouslyprovided instruction, such as is described herein). Moreover, in certainimplementations the referenced notifications (such as those generated at4015) can include various navigation instructions that characterize anaspect of the navigation between the first location and the secondlocation as an instruction to continue performing at least onenavigation operation (e.g., a navigation operation that was already oris currently being performed, such as during the same trip). It shouldbe understood that ‘navigation operation’ can refer to adriving/transportation operation or maneuver, such as may be performedby the user (and which may not necessarily correspond to a navigationinstruction that is explicitly provided by a navigation application),for example, an instruction to continue driving straight (which the usermay already be currently doing and which a navigation application wouldnot otherwise explicitly instruct).

At 4020, the referenced notification(s) can be provided, such as inrelation to a location associated with the one or more disparities (suchas those determined at 4010) (e.g., at a defined time or distanceinterval prior to the arrival of the user at a location at which theroutes diverge). In certain implementations the notification(s) can beprovided via one or more interfaces (e.g., interfaces of the deviceand/or interfaces external to the device). Examples of such interfacesinclude but are not limited to a display interface, an audio interface,an illumination interface, or a haptic interface. Moreover, in certainimplementations the referenced notification can be provided in a mannerthat is relatively more prominent than the notification(s) provided withrespect to the prior navigation operations (that is, relatively moreprominent than notifications provided previously/earlier within the sametrip) (e.g., in order to draw greater attention to the notification).For example, the notification can be provided in a manner that is, forexample, relatively louder, relatively faster, relatively brighter,relatively stronger, relatively slower, relatively more redundant (e.g.,by repeating an instruction multiple times), relatively longer,relatively more dynamic (e.g., moving more/faster on display),relatively bolder, relatively larger (e.g., in font), relatively morered or yellow in hue, etc., than the notifications provided with respectto the prior navigation operations (that is, relatively louder, etc.,than notifications provided previously/earlier within the same trip). Incertain implementations, the referenced notification(s) can be providedin a different voice, tone of voice, etc. (e.g., in a ‘male’ voice, incontrast to the manner in which other notifications are provided, e.g.,in a ‘female’ voice) than the notifications provided with respect to theprior navigation operations. In certain implementations, the referencednotification(s) can be provided in conjunction with non-verbalsounds/tones (e.g., such instructions can be preceded by a ‘beep’).Additionally, in certain implementations a degree to which the operationis relatively unlikely to be complied with can be determined (such as ina manner described herein) and, based on the degree to which thenavigation instruction is relatively unlikely to be complied with, atleast one of the one or more interfaces at which to provide the one ormore notifications can be selected (for example, one interface—e.g., anaudio interface—can be selected if the operation is highly unlikely tobe complied with, while another interface—e.g., a visual interface—canbe selected if the operation is relatively less unlikely to be compliedwith). Moreover, in certain implementations a degree to which theoperation is relatively unlikely to be complied with can be determinedand, based on the degree to which the navigation instruction isrelatively unlikely to be complied with, the notification can beprovided in a manner that is relatively more prominent than one or moreother notifications provided with respect to the one or more priornavigation operations (for example, with respect to an operation that ishighly unlikely to be complied with, the navigation instruction can beprovided in a highly prominent manner—e.g., considerably louder thanother instructions during the trip—while with respect to an operationthat is relatively less unlikely to be complied with, the navigationinstruction can be provided in a relatively less prominent manner—e.g.,only somewhat louder than other instructions during the trip). At 4025,the providing of a notification, such as a notification that does notcorrespond to the one or more disparities (e.g., those determined at4010), can be precluded, suppressed, or otherwise modified/restricted,such as in a manner described herein.

FIG. 48 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4805 one or more navigationinstructions can be computed or received, such as between a firstlocation and a second location. It should be understood that, in certainimplementations the referenced locations (e.g., the first locationand/or the second location) can be practically any points along anavigation route (that is, not necessarily the origin or destination ofa particular trip). At 4810, the one or more navigation instructions canbe processed, such as in relation to at least one of (a) one or morepreviously computed navigation instructions between the first locationand the second location or (b) one or more previously traveled routesbetween the first location and the second location to determine one ormore disparities between the one or more navigation instructions and theat least one of (a) one or more previously computed navigationinstructions between the first location and the second location, (b) apreviously traveled route between the first location and the secondlocation, or (c) one or more frequently traveled routes between thefirst location and the second location. At 4815, one or morenotifications can be generated, such as based on the one or moredisparities. Moreover, in certain implementations the referencednotifications can include various navigation instructions thatcharacterize an aspect of the navigation between the first location andthe second location as an instruction to continue performing at leastone of the one or more navigation instructions that were previouslyprovided, such as is described herein. Additionally, in certainimplementations the referenced navigation instructions (that areincluded in the referenced notification) can be those instructions thatwere previously provided during the same trip as the navigationinstructions computed/received at 4805 (e.g., an instruction thatrepeats a previously provided instruction/instructs the user to continueperforming a previously provided instruction, such as is describedherein). Moreover, in certain implementations the referencednotifications (such as those generated at 4815) can include variousnavigation instructions that characterize an aspect of the navigationbetween the first location and the second location as an instruction tocontinue performing at least one navigation operation (e.g., anavigation operation that was already or is currently being performed,such as during the same trip). It should be understood that ‘navigationoperation’ can refer to a driving/transportation operation or maneuver,such as may be performed by the user (and which may not necessarilycorrespond to a navigation instruction that is explicitly provided by anavigation application), for example, an instruction to continue drivingstraight (which the user may already be currently doing and which anavigation application would not otherwise explicitly instruct).

At 4820, the referenced notifications can be provided in relation to alocation associated with the one or more disparities (such as thosedetermined at 4810) (e.g., at a defined time or distance interval priorto the arrival of the user at a location at which the routes diverge).In certain implementations the notification(s) can be provided via oneor more interfaces (e.g., interfaces of the device and/or interfacesexternal to the device). Examples of such interfaces include but are notlimited to a display interface, an audio interface, an illuminationinterface, or a haptic interface. Moreover, in certain implementationsthe referenced notification can be provided in a manner that isrelatively more prominent than the notification(s) provided with respectto the prior navigation operations (that is, relatively more prominentthan notifications provided previously/earlier within the same trip)(e.g., in order to draw greater attention to the notification). Forexample, the notification can be provided in a manner that is, forexample, relatively louder, relatively faster, relatively brighter,relatively stronger, relatively slower, relatively more redundant (e.g.,by repeating an instruction multiple times), relatively longer,relatively more dynamic (e.g., moving more/faster on display),relatively bolder, relatively larger (e.g., in font), relatively morered or yellow in hue, etc., than the notifications provided with respectto the prior navigation operations (that is, relatively louder, etc.,than notifications provided previously/earlier within the same trip). Incertain implementations, the referenced notification(s) can be providedin a different voice, tone of voice, etc. (e.g., in a ‘male’ voice, incontrast to the manner in which other notifications are provided, e.g.,in a ‘female’ voice) than the notifications provided with respect to theprior navigation operations. In certain implementations, the referencedoperation(s) can be provided in conjunction with non-verbal sounds/tones(e.g., such instructions can be preceded by a ‘beep’). Additionally, incertain implementations a degree to which the operation is relativelyunlikely to be complied with can be determined (such as in a mannerdescribed herein) and, based on the degree to which the navigationinstruction is relatively unlikely to be complied with, at least one ofthe one or more interfaces at which to provide the one or morenotifications can be selected (for example, one interface—e.g., an audiointerface—can be selected if the operation is highly unlikely to becomplied with, while another interface—e.g., a visual interface—can beselected if the operation is relatively less unlikely to be compliedwith). Moreover, in certain implementations a degree to which theoperation is relatively unlikely to be complied with can be determinedand, based on the degree to which the navigation instruction isrelatively unlikely to be complied with, the notification can beprovided in a manner that is relatively more prominent than one or moreother notifications provided with respect to the one or more priornavigation operations (for example, with respect to an operation that ishighly unlikely to be complied with, the navigation instruction can beprovided in a highly prominent manner—e.g., considerably louder thanother instructions during the trip—while with respect to an operationthat is relatively less unlikely to be complied with, the navigationinstruction can be provided in a relatively less prominent manner—e.g.,only somewhat louder than other instructions during the trip). At 4825,the providing of a notification, such as a notification that does notcorrespond to the one or more disparities (e.g., those determined at4810), can be precluded, suppressed, or otherwise modified/restricted,such as in a manner described herein.

It can be appreciated that navigation applications generally instruct auser when to take certain actions (e.g., “in 800 meters turn right”, “atthe roundabout take the 2^(nd) exit,” etc.). Accordingly, in certainimplementations such applications can be improved/augmented byconfiguring them to provide instructions to users pertaining to when notto take certain actions (e.g., “in 800 meters, at the intersection, donot take a left”, or “in 800 meters, at the intersection, go straight”).Such functionality can be advantageous to users when a route to theircurrent destination that is usually optimal is temporarily not optimal(e.g., due to road work, heavy traffic, etc.). For example, if the routethat is generally fastest from a user's home to the user's place of workincluded turning left at a particular intersection, but that route wasnot optimal on a particular day/time (e.g., due to road work, heavytraffic, etc.), and the currently best route involved proceedingstraight at such intersection, existing navigation systems might simplyomit the “turn left” instructions. However, such an omission may wellnot be recognized by a user, particularly one who frequently travelssuch a route (e.g., a commuter), and such user may likely turn left atthe referenced intersection by force of habit. Accordingly, providing anexplicit negative instruction such as “do not turn left at” or animplicit negative instruction such as “go straight at [the referencedintersection]” and/or any other such technique that can emphasize and/oralerting the user to the recommended change can be advantageous in suchsituations. Moreover, such techniques can be particularly useful whenthe user's ordinary routes are learned/observed over time and theinstructions/notifications provided by the navigation application aregenerated and provided relative to such learned routes. In doing so,changes in routes relative to those that the user follows often caninclude negative instructions, whereas changes to routes that the userknows less well may be omitted (or less prominently emphasized), therebyfurther improving the user's driving experience. In anotherimplementation, a navigation application can provide such implicitnegative instruction(s) by advising a device user to “make a left nowinstead of at the next intersection”. One exemplary implementation isdepicted in FIG. 49.

FIG. 97 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 9710 a first set of navigationinstructions can be received. Such a first set of navigationinstructions can include navigation instructions such as from a firstorigin to a first destination. At 9720 a second set of navigationinstructions can be received. Such a second set of navigationinstructions can include navigation instructions such as from a secondorigin to a second destination. Moreover, in certain implementations thereferenced second set of navigation instructions can include one or morepreviously traveled routes (e.g., routes previously traveled by theuser), one or more frequently traveled routes (e.g., routes frequentlytraveled by the user), and/or one or more previously computed navigationinstructions. It should be noted that, in certain implementations, thefirst origin can be equivalent to the second origin and/or the firstdestination can be equivalent to the second destination. At 9730, thefirst set of navigation instructions and the second set of navigationinstructions can be processed. In doing so, one or more disparitiesbetween the first set of navigation instructions and the second set ofnavigation instructions can be determined, such as with respect to oneor more locations. In certain implementations, one or more instructionsthat are present in both the first set of navigation instructions andthe second set of navigation instructions and one or more disparitiesbetween the first set of navigation instructions and the second set ofnavigation instructions can be determined. Such disparities can includeone or more instructions that follow/succeed the instructions that arepresent in both the first set of navigation instructions and the secondset of navigation instructions that are present in the second set ofnavigation instructions but are not present in the first set ofnavigation instructions and/or or that are present in the first set ofnavigation instructions but are not present in the second set ofnavigation instructions. At 9740, one or more notifications can begenerated, such as based on the one or more disparities (such as thosedetermined at 9730). In certain implementations, the referencednotifications can include a notification not to perform one or moreinstructions from the first set of navigation instructions that areassociated with the one or more locations and that are not present inthe second set of navigation instructions and/or a notification toperform one or more instructions from the second set of navigationinstructions that are associated with the one or more locations and thatare not present in the first set of navigation instructions. At 9750,the referenced notifications (such as those generated at 9740) can beprovided, such as in relation to the one or more locations.

FIG. 98 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 9810 a navigation instruction can be received, such as in relation toa location.

At 9820 the navigation instruction can be processed, such as withrespect to one or more prior navigation operations performed (and/orwith respect to previously used routes, e.g., routes that areregularly/frequently used, such as by the same user, that include thesame or similar location) with respect to the location. It should beunderstood that ‘navigation operations’ can refer to adriving/transportation operations or maneuvers, such as may be performedby the user (and which may not necessarily correspond to a navigationinstruction that is explicitly provided by a navigation application). Itshould also be understood that the referenced ‘prior navigationoperations’ can refer to navigation operations that were performed(e.g., by the same user) during a previous trip/navigation instanceand/or during the same trip/navigation instance. In certainimplementations the referenced prior navigation operations can includenavigation operations that are associated with a user with respect towhich the notification is provided (as described herein). Moreover, incertain implementations the referenced prior navigation operations caninclude navigation operations that are associated with a firstuser/group of users, while the notification(s) referenced herein areprovided with respect to another user or users. Additionally, in certainimplementations the navigation instruction can include a navigationinstruction that is provided with respect to travel in a first directionand the referenced prior navigation operations can include navigationoperations performed with respect to travel in the first (that is, thesame) direction, such as is described herein.

At 9830 the prior navigation operation(s) performed with respect to thelocation can be processed. In doing so, a relative predominance of aparticular navigation operation can be determined, such as with respectto the referenced location (e.g., the location in relation to which thenavigation instruction is received at 9810). Moreover, in certainimplementations the navigation instruction can be processed with respectto the particular navigation operation. Additionally, in certainimplementations the navigation operations performed with respect totravel in a first direction can be processed. In doing so a relativepredominance of a particular navigation operation with respect to travelin the first direction can be determined, such as with respect to thereferenced location.

At 9840 a notification can be generated. In certain implementations sucha notification can be generated based on a determination that thenavigation instruction (such as that received at 9810) deviates from theone or more prior navigation operations (or previously/frequentlytraveled/used routes). Such a notification can include a notificationnot to perform (e.g., with respect to the referenced location) anoperation in accordance with the one or more prior navigation operations(for example, “at the upcoming intersection, don't continue straightlike you normally do”), and/or a notification to perform the navigationinstruction with respect to the location (e.g., “at the upcomingintersection, turn right”).

At 9850 the notification can be provided. In certain implementations,such a notification can be provided in relation to the location.Moreover, in certain implementations the notification can be provided inrelation to the location (e.g., at a defined distance/time intervalprior to reaching the location) based on the relative predominance (suchas that determined at 9830). Additionally, in certain implementationsthe notification can be provided via one or more interfaces (e.g.,interfaces of the device and/or interfaces external to the device).Examples of such interfaces include but are not limited to a displayinterface, an audio interface, an illumination interface, or a hapticinterface. Moreover, in certain implementations the referencednotification can be provided in a manner that is relatively moreprominent than the notification(s) provided with respect to the priornavigation operations (that is, relatively more prominent thannotifications provided previously/earlier within the same trip) (e.g.,in order to draw greater attention to the notification). For example,the notification can be provided in a manner that is, for example,relatively louder, relatively faster, relatively brighter, relativelystronger, relatively slower, relatively more redundant (e.g., byrepeating an instruction multiple times), relatively longer, relativelymore dynamic (e.g., moving more/faster on display), relatively bolder,relatively larger (e.g., in font), relatively more red or yellow in hue,etc., than the notifications provided with respect to the priornavigation operations (that is, relatively louder, etc., thannotifications provided previously/earlier within the same trip). Incertain implementations, the referenced notification(s) can be providedin a different voice, tone of voice, etc. (e.g., in a ‘male’ voice, incontrast to the manner in which other notifications are provided, e.g.,in a ‘female’ voice) than the notifications provided with respect to theprior navigation operations. In certain implementations, the referencednotification(s) can be provided in conjunction with non-verbalsounds/tones (e.g., such instructions can be preceded by a ‘beep’).Additionally, in certain implementations a degree to which the operationis relatively unlikely to be complied with can be determined (such as ina manner described herein) and, based on the degree to which thenavigation instruction is relatively unlikely to be complied with, atleast one of the one or more interfaces at which to provide the one ormore notifications can be selected (for example, one interface—e.g., anaudio interface—can be selected if the operation is highly unlikely tobe complied with, while another interface—e.g., a visual interface—canbe selected if the operation is relatively less unlikely to be compliedwith). Moreover, in certain implementations a degree to which theoperation is relatively unlikely to be complied with can be determinedand, based on the degree to which the navigation instruction isrelatively unlikely to be complied with, the notification can beprovided in a manner that is relatively more prominent than one or moreother notifications provided with respect to the one or more priornavigation operations (for example, with respect to an operation that ishighly unlikely to be complied with, the navigation instruction can beprovided in a highly prominent manner—e.g., considerably louder thanother instructions during the trip—while with respect to an operationthat is relatively less unlikely to be complied with, the navigationinstruction can be provided in a relatively less prominent manner—e.g.,only somewhat louder than other instructions during the trip).

At 9860, the providing of a notification that corresponds to the one ormore prior navigation operations (such as those referenced at 9820) canbe precluded, suppressed, or otherwise modified/restricted, such as in amanner described herein.

It should be noted that the navigation techniques described herein canbe applied/configured with respect to any/all forms of navigations(e.g., all forms of motor vehicles, non-motorized vehicles, pedestrianactivities and whether outside, inside, on Earth, in space, in anymedium (e.g., air, water, other), whether initiated by the user, a 3rdparty or autonomously, etc.).

In certain implementations, when a user travels along a route (e.g., atleast one point on which) she often/regularly travels or is at alocation (e.g., at an intersection) she is often/regularly at, but inher current trip she wishes to reach a destination to which she doesn'ttravel to most often/as regularly/regularly, a navigation applicationcan be configured to generate/provide a ‘special’ instruction (e.g., anegative instruction (explicit or implicit), an instruction with specialaudio, visual and/or haptic emphasis), before or at (or even after) thelocation at which the route (e.g., best route, the route she has electedto follow) to her current destination can be determined to deviate fromthe route (or from one or more routes) that the user travels moreoften/more regularly/regularly (to other destinations).

For example, as shown in FIG. 80, a user regularly travels from home towork each morning (‘A’ to ‘C’). On a particular day, the user is askedto drop a child off at school (‘A’ to ‘B’). The route to school has someinitial overlap with the route to work (in this case the overlap wasinitial, but the overlap may occur at any location/time along a routenot necessarily at the beginning of the route and may be arbitrarilyshort (or long) in distance/time), but at a particular intersection(‘D’), the route to school requires continuing straight, whereas theroute to work requires turning right. Accordingly, a ‘special’instruction can be generated/provided by the navigation application,alerting the user to the fact that she needs to take an action that isdifferent from what she is used to. For example, the navigationapplication can provide an audio, visual and/or haptic instruction thatindicates “In 300 meters, at the intersection, do not make a right handturn but continue straight instead” (an explicit instruction) or “In 300meters, at the intersection, continue straight” (an implicitinstruction). This can be done in a manner that emphasizes (i.e., callsthe user's attention to) the instruction in a manner consistent with theone or more interfaces through which instructions are delivered and withthe design of the particular navigation application (not allapplications have the same “language” with their users), e.g., a louderor longer instruction if via audio interface, a larger or brighter ormoving instructions if via visual interface, a stronger vibration, etc.

By way of further example, as shown in FIG. 83, a user regularly travelsalong route ‘A-C-D-B,’ such as from home to work. However, on account oftraffic between points ‘C’ and ‘D,’ currently the best (e.g., most timeefficient) route is ‘A-C-E-D-B.’ Accordingly in such a scenario, a‘special’ instruction can be generated/provided by the navigationapplication, alerting the user to the fact that she needs to take anaction that is different from what she is used to. For example, thenavigation application can provide an audio, visual and/or hapticinstruction that indicates “In 300 meters, at the intersection, do notcontinue straight (as you normally do) but make a left hand turn butinstead,” such as in the manner described herein.

By way of yet further example, as shown in FIG. 84, a user regularlytravels along route ‘A-C-E-B,’ such as from home to work. However, onaccount of traffic between points ‘E’ and ‘B,’ currently the best (e.g.,most time efficient) route is ‘A-C-D-B.’ Accordingly in such a scenario,a ‘special’ instruction can be generated/provided by the navigationapplication, alerting the user to the fact that she needs to take anaction that is different from what she is used to. For example, whenapproaching ‘C’ (e.g., the point at which the current bestroute—‘A-C-D-B’—diverges from the regular route—‘A-C-E-B’) thenavigation application can provide an audio, visual and/or hapticinstruction that indicates “In 300 meters, at the intersection, do not(as you normally do) make a left hand turn but continue straightinstead” (an explicit negative instruction) or “continue straight” (animplicit negative instruction), such as in the manner described herein.It should be noted that other navigation applications, which do notaccount for the manner in which previous routes/trips may affect how auser may relate to a current set of instructions being provided. Assuch, in the illustrated scenarios, while other navigation applicationsmay provide no instruction(s) when the user is determined to beapproaching the point at which the current route diverges from a regularor common route associated with the user (and particularly in thescenario illustrated in FIG. 84 in which the user is supposed to simplycontinue in the same direction they were already traveling—a scenario inwhich existing navigation applications are unlikely to provide anyinstructions), as described herein, a ‘special’ instruction can begenerated and provided, instructing the user not to make a turn theyoften make and/or to perform (or continue performing) an operation theyare already performing.

FIG. 85 depicts an exemplary set of navigation instructions 8510 whichinclude a ‘negative instruction’ 8520 that instructs the user not totake perform a particular operation (‘don't take the bridge’). As noted,such a ‘special’ instruction can be generated based on various previoustrips/navigation scenarios with respect to which a user may havedemonstrated a likelihood to perform such an operation (e.g., the usermay often take the referenced bridge). Such an instruction can then beprovided in relation to (e.g., shortly before) the location associatedwith such an instruction, thereby alerting the user to the fact thatthey should not follow their regular/commonly taken route. It should benoted that while FIG. 85 depicts a visual instruction (that may bedisplayed on a device, for example), the referenced instruction can beprovided via any number of interfaces (e.g., audio, haptic, etc.), asdescribed herein.

In another example, as shown in FIG. 81, over the past month, a userarrived at the intersection that her current route is now approaching100 times, of which she turned to the north 80 times and she turned tothe south 20 times. If her current route requires that she go in anydirection other than north at this intersection, a ‘special’ instructionaccounting for the user's prior history can be generated/provided. Inanother implementation, such techniques can further account fordirection of travel on the user's previous trips is taken into accountin determining whether a special instruction should be issued (whilethere is, a priori, no limit to how many or how frequently a navigationapplication can issue special instructions to a user, it may beadvantageous to limit the number of special instructions to situationsin which they have a higher likelihood of preventing user error, or elsethey may become ineffective). For example, as shown in FIG. 82, if theuser arrived at the intersection from the east only 20 of the 100 times,but in each such case the user turned south, and in the current routethe user is arriving at the intersection from the east but is supposedto turn north the navigation application can minimize the chance of usererror by issuing a special instruction, even though “north” was the mostpopular direction for the user to go at this intersection when analyzedblind to “direction of approach”.

In one implementation, which can be particularly useful to navigationapplications where the device user's travelling patterns aredetermined/learned, one or more notifications/alerts can be provided inadvance, such as to the fact that an upcoming trip is likely to takemore/less time than usual (e.g. a commute), so that the user can adjusthis/her departure time accordingly. Such notification(s) can begenerated/determined and/or provided, for example, based on an estimateof the trip travel time that is likely to prevail for a trip that isslated to start at or around the hour that the device user is likely to(or has advised that he/she will) begin his/her trip. Such estimatedtrip travel time can be determined/derived based on one or more of (a) acomparison of current traffic (e.g., determined today) at one or morepoints in time along the referenced possible routes for the referencedtrip with historical traffic data collected/determined with respect tosuch times along such routes, (b) acquiring/obtaining data (time,location) pertaining to specific events set (or likely) to occur on thatday (e.g., a sporting event, holiday, weather conditions such asrain/snow, etc.) and which may cause changes in traffic patterns alongsaid routes, and/or (c) determining/acquiring data pertaining tovehicular or infrastructure problems/incidents (e.g., crashes, roadwork, holes in the road, etc.) that may influence/affect trafficpatterns along the referenced route(s). It should be noted that the timethat the device user is likely to begin such a trip can bedetermined/derived from one or more factors such as the regular/usualtime the user begins such commute, the device's alarm clock settings,entries in the device's/user's calendar and/or user input indicating adesired departure time or destination arrival time.

FIG. 66 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 6610, one or more operations (e.g., from a set of navigationaloperations, such as a set of instructions generated and/or provided by anavigation instruction application) associated with a relatively lowerlikelihood of compliance can be identified. In certain implementations,such a relatively lower likelihood of compliance (e.g., with respect tothe referenced operation) can be determined based on one or moregeographic locations (e.g., a location at which the device or vehicle istraveling or present in—for example, in the left-most lane of a highwaywhen the user is being directed to exit very shortly via the right-mostlane of the highway), a speed (e.g., a speed at which the operation isrelatively less likely to be complied with—for example, if the vehicleis traveling at 50 miles per hour and is expected to stop shortly),and/or a device state of the device (e.g., a state or setting of thedevice with respect to which it is relatively less likely that anoperation is to be complied with, for example, a volume state of thedevice and/or an application executing thereon—e.g., if the device ornavigation application is on a low volume or mute setting, it isrelatively less likely that the user is aware of upcoming instructions,a display state of the device and/or an application executing thereonthe device—e.g., if the display of the device is on a low brightness or‘off’ setting, it is relatively less likely that the user is aware ofupcoming instructions). Additionally, in certain implementations thereferenced operation(s) (e.g., a geographic location associated with theoperation, such as the location at which a turn is to be made) can becompared with a geographic location associated with a device todetermine that the operation is relatively less likely to be compliedwith (e.g., by determining that the device is considerably distant fromthe location of the operation, such that it is unlikely that theoperation will be performed) (it should be understood that the devicestate of the device can also be accounted for in this scenario indetermining that the operation is less likely to be complied with, suchas in a manner described herein). Moreover, in certain implementationsthe referenced operation can be determined to be relatively less likelyto be complied with based on one or more environmental conditions, suchas those that are perceptible to one or more devices (e.g., the level ofaudible noise in the environment surrounding the device, as can beperceived by the microphone of the device, traffic conditions, weatherconditions, etc.). In certain implementations, a determination can bemade, based on a device state of one or more first devices, that thereferenced operation is relatively less likely to be complied with.Additionally, in certain implementations a degree to which the operationis relatively unlikely to be complied with can be determined. Moreover,in certain implementations the referenced operation (which is relativelyless likely to be complied with) can include a turn, a stop, a start, adirection change (e.g., forward vs. reverse), a continuation of aprevious/current operation (e.g., to continue straight), a lane change,a previously performed operation, or an exit, and/or any other suchnavigation or driving-related operation/instruction.

At 6620, one or more notifications can be generated and/or provided. Incertain implementations, such notifications can correspond to anoperation (such as the operation identified at 6610 as being relativelyless likely to be complied with). Moreover, in certain implementationssuch notifications can be provided based on/in relation to a devicestate of a device (e.g., an audio or display setting, etc.).Additionally, in certain implementations the referenced notificationscan include one or more instructions that are directed or otherwiseconfigured to increase the likelihood of compliance with the identifiedoperation (e.g., in a scenario in which it is unlikely that a usertraveling in the left-most lane of a highway will comply with aninstruction to exit via the right lane, a notification to the effect of“you must exit right shortly, move over now!” can be generated and/orprovided). Moreover, in certain implementations the referencednotifications can be generated and/or provided based on the degree towhich the operation is relatively unlikely to be complied with (such asis determined at 6610). Additionally, in certain implementations one ormore interfaces at which to provide the referenced notifications can beselected, such as based on the degree to which the operation isrelatively unlikely to be complied with. Moreover, in certainimplementations the referenced notifications can be modified, such asbased on/in relation to the degree to which the operation is relativelyunlikely to be complied with (e.g., by adjusting (a) the volume state ofthe device, (b) a volume state of an application executing on thedevice, (c) a display state of the device, (d) a display state of anapplication executing on the device, (e) a haptic state of the device,and/or (f) a haptic state of an application executing on the device).Additionally, in certain implementations the referenced notificationscan be provided to a device associated with a second vehicle. Suchnotifications can reflect, for example, that a first vehicle isrelatively less likely to comply with a particular operation.Additionally, in certain implementations one or more vehiclefunctionalities can be initiated, such as based on a degree to which theoperation is relatively unlikely to be complied with (e.g., activating aleft-turn lane-change mechanism in the vehicle based on a determinationthat the driver is unlikely to comply with a left-turn operation). Incertain implementations, the referenced notifications (e.g.,notifications corresponding to the referenced operation) can be providedin relation to one or more second devices. In certain implementations,such second devices can be/include one or more of the first devicesreferenced at 6610, while in other implementations the referenced firstdevices can be/include one or more of the second devices. It should alsobe understood that, in certain implementations, the device statereferenced herein can include a volume state of the referenced seconddevice(s), a volume state of an application executing on the seconddevice(s), a display state of the second device(s), a display state ofan application executing on the second device(s), a haptic state of atleast one of the second device(s), and/or a haptic state of anapplication executing on at least one of the one or more second devices.As noted, in certain implementations the one or more first devices caninclude at least one of the one or more second devices and/or the one ormore second devices can include at least one of the one or more firstdevices. Moreover, in certain implementations the referencednotifications can include but are not limited to audio notification(s),visual notification(s), haptic notification(s), etc.

At 6630, the providing of a notification that does not correspond to theoperation (such as the operation identified at 6610) can be precluded,suppressed, or otherwise modified/restricted, such as in a mannerdescribed herein.

By way of further illustration, in certain implementations, when theprobability that a user is unlikely to comply with one or moreoperations and/or is going to make some other form of mistake (e.g.,deviate from a particular route such as the optimal route or theselected route) exceeds one or more threshold values, a navigationapplication can be configured to generate and/or provide aninstruction/notification (e.g., audio, visual, haptic, etc.) that can beprovided to the user in one or more ways. In certain implementations,such an instruction/notification can be provided via an interface (e.g.,sound, visual, haptic), such as an interface that is integrated into thevehicle (e.g., infotainment system, steering wheel, seat, floor,windshield, rear view mirror, etc.) and/or on a mobile device present inthe vehicle. Moreover, in certain implementations such aninstruction/notification can be modulated in strength (e.g., withrespect to volume, size, length, amplitude, frequency, etc.), such asbased upon the severity and/or the probability of the pending lack ofcompliance/mistake. For example, if an upcoming operation/instructiondictates/recommends to make a left-hand turn at a traffic light orintersection and the user/vehicle can be determined to be fastapproaching the light/intersection in the far right lane on a six-laneroad, it can be determined that the user is relatively/highly likely todeviate from the recommended operation/instruction. Accordingly, thenavigation application can generate one or more alerts and/or providesuch alerts to which can notify the driver to this upcoming error (e.g.,by emitting an audible phrase, e.g., “You are supposed to turn left”,“Warning: You're in the right lane, but are supposed to turn left in 20meters,” etc.).

In certain implementations, various factors and/or states (such as thoserelated to the navigation application and/or various other devices,elements, etc.) can be used to determine the probability of the that auser (e.g., a driver) is unlikely to comply with one or more operationsand/or is going to make some other form of mistake. Examples of suchfactors, states, etc., include but are not limited to: whether thescreen of the device on which the navigation application is to bevisually displayed in an ‘on’ state or otherwise visible, and, even ifthe display is ‘on,’ whether the navigation application is in theforeground of the device/operating system (such that it is readilyvisible) or in the background (such that it is not readily visible),environment/conditions in which the vehicle is traveling (e.g., the lanelocation as perceived/determined by one or more in-vehicle cameras orextra-vehicle cameras, e.g., transmitting information using vehicle toinfrastructure (V2I) protocols), the speed of the vehicle asdetermined/perceived by a GPS or speedometer (whether in-vehicle orextra-vehicle), traffic conditions as perceived/determined by one ormore cameras or through 3rd party information, the noise level in oraround the vehicle (which may affect the user's ability to hearinstructions), and/or any activities in which the user is engaged (e.g.,a phone call, which may affect the user's cognitive ability to “consume”instructions).

For example, a vehicle that is determined (e.g., through visual capturefrom one or more cameras), to have a solid line on its left and a dashedline on its right (i.e., likely in the left lane), can be determined tohave a relatively higher probability of not complying with anoperation/instruction/direction to turn right at an intersection 20meters ahead than a vehicle that is determined to have a solid line onits right and a dashed line on its left (i.e., likely in the rightlane). Accordingly, in scenarios in which anoperation/instruction/direction is determined to be relatively likelynot to be complied with, the navigation application can be configured togenerate and/or provide one or more corrective instructions (such as aredescribed herein).

It should also be noted that, as in the case with respect to ‘negativeinstructions,’ as described herein (which, for example, instruct a usernot to perform a particular operation—such as not to follow a route thatthe user may otherwise be accustomed to following), the described‘corrective instructions’ can be explicit (for example, “you are aboutto turn left or go straight—but you are actually supposed to turnright”) or implicit (e.g., repeating the instruction “turn right in 20meters” one or more times).

In another example, if a vehicle that is supposed to take an upcominghighway exit cannot be (or is not) determined to demonstrate theappropriate signs of slowing down as it approaches the location at whichit is to exit, the navigation application can generate and/or provide anexplicit corrective instruction, such as by vibrating the right part ofthe steering wheel.

In another example, if a vehicle is not supposed to take an upcominghighway exit but can be/is determined to demonstrate signs of slowingdown as it approaches the (incorrect) exit, the navigation applicationcan generate and/or provide an explicit corrective instruction, such asby vibrating the left part of the steering wheel.

In another implementation, user interfaces can be chosen and/or modifiedbased upon the effectiveness of the delivery of information to a uservia a particular interface (e.g., audio, visual, haptic), whether suchinterface is integrated into the vehicle (e.g., infotainment system,steering wheel, seat, floor, windshield, rear view mirror) or on amobile device present in the vehicle, based upon the activitiesdetermined to be taking place on the vehicle hardware and/or on themobile device (e.g., volume setting, visibility (e.g.,foreground/background), brightness setting, phone call in progress) orin the user's environment (e.g., loud noise present, bright sunshinepresent). Based upon the user's activities (e.g., current foregroundapplication on infotainment system or mobile device), the state of oneor more interfaces (e.g., infotainment system or mobile speaker volumeis low) and/or the environmental conditions (e.g., windows open and lotsof noise in car), one or more interface actions can be used to betterconvey information to the user. For example, a navigation applicationmay choose to deliver its instructions at higher volume based on adetermination that there is a radio playing in a vehicle. If that sameradio is playing at a volume at which audio instructions may not beeffective, the navigation application and/or the infotainment systemand/or the mobile device can be configured to provide informationvisually (e.g., on the windshield) in lieu of or in addition toproviding audio instructions. For example, in a scenario in which anavigation application is running in the background on a mobile device(such that audio instructions are provided to the user from time totime, but no visual instructions are readily viewable), upon determiningthat the user is not likely to effectively receive one or more audioinstruction(s) (e.g. “in 500 meters turn left”) (e.g., because the radiois playing at a high volume or the user is engaged in a hand-free phonecall) the mobile device can be configured to provide visual instructionsin lieu of (or in addition to) the audio instruction, or can deliver theinstruction by causing the left side of the driver's seat to vibrate(e.g., through communication with one or more in-vehicle systems). Itshould be understood that such techniques can be employed with respectto ‘negative instructions’ and/or a ‘corrective instructions,’ such asare described herein.

The fact that a user is less likely to comply with the instructionsand/or has received a corrective instruction also reflects that thelikelihood that the user is going to engage in one or more dangerousdriving behaviors in the near future is increased. Accordingly, suchinformation can useful, such as to provide to vehicles in the vicinityof the user and/or can be shared with them, for example, using V2V orV2I techniques known to those of ordinary skilled in the art.

In another implementation, a navigation application can also beconfigured to control certain vehicle functionality. For example whenthe navigation application instructs the driver to make a right-handturn (and, in certain implementations, only upon the user's confirmationor not declining such instruction), the vehicle's lane change signalingdevice can be activated to indicate an upcoming right hand turn, such asat a calculated distance before such upcoming turn (e.g., at the bestpractices distance before the turn, given the current speed and otherconditions). Moreover, in certain implementations, such actions can beinitiated whether the referenced instruction is a negative instructionor a corrective instruction.

FIG. 67 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 6710, a first set of navigational operations (e.g., directions,instructions, etc.) can be identified/received, such as between anorigin and a destination. In certain implementations, such an origin canbe an initial/original location or a current location. Moreover, incertain implementations such a destination can include an ultimate/finalor intermediate destination. In certain implementations, the referencedset of operations can include those that have been performed (e.g., withat least a defined frequency) by a user associated with the alternativeset of navigational operations (such as those referenced at 6720).Additionally, in certain implementations the referenced set ofnavigational operations can be those that have been performed (e.g.,with at least a defined frequency) by one or more users. Additionally,in certain implementations the first set of navigational operations caninclude a set of navigational operations previously traveled by a userassociated with a device.

At 6720, an alternative set of navigational operations can be determinedand/or received. In certain implementations, such an alternative set ofnavigational operations (e.g., between the origin and the destination)that is likely to be more efficient (for example, more time efficient,more distance efficient, more energy efficient, more safe, moreefficient with respect to one or more usage fees, more attractive, beassociated with more points of interest, and/or more familiar) (e.g., ata certain point in time) than the first set of navigational operations(such as those identified/received at 6710) can be determined. Moreover,in certain implementations the alternative set of navigationaloperations can be determined based on one or more additional/othercriteria (e.g., in addition to/instead of efficiency). For example, suchalternative set of navigational operations can be determined based onsafety (e.g., the usual route is icy/wet/unsafe), legality (e.g., acertain road is presently closed or has a temporarily lower speed limit,a certain turn cannot be made at certain hours/the present time, etc.).

At 6730, the alternative set of navigational operations (such as aredetermined at 6720) can be compared with the first set of navigationaloperations (such as those identified/received at 6710). In doing so, oneor more operations included in the alternative set of navigationaloperations that deviate from the first set of navigational operationscan be identified.

At 6740, one or more of the one or more operations included in thealternative set of navigational operations that deviate from the firstset of navigational operations (such as are identified at 6730) can beprovided (e.g., via one or more interfaces). In certain implementations,information pertaining to and/or otherwise reflecting a determinationthat the alternative set of navigational operations is likely to be moreefficient than the first set of navigational operations can be provided.Additionally, in certain implementations the referenced operations canbe provided via one or more interfaces (e.g., interfaces of the deviceand/or interfaces external to the device). Examples of such interfacesinclude but are not limited to a display interface, an audio interface,an illumination interface, or a haptic interface. Moreover, in certainimplementations the referenced operations can be provided in a mannerthat is relatively more prominent than the notification(s) provided withrespect to other navigation operations (that is, relatively moreprominent than notifications provided previously/earlier within the sametrip) (e.g., in order to draw greater attention to the notification).For example, the operations can be provided in a manner that is, forexample, relatively louder, relatively faster, relatively brighter,relatively stronger, relatively slower, relatively more redundant (e.g.,by repeating an instruction multiple times), relatively longer,relatively more dynamic (e.g., moving more/faster on display),relatively bolder, relatively larger (e.g., in font), relatively morered or yellow in hue, etc., than the notifications provided with respectto the prior navigation operations (that is, relatively louder, etc.,than notifications provided previously/earlier within the same trip). Incertain implementations, the referenced operations can be provided in adifferent voice, tone of voice, etc. (e.g., in a ‘male’ voice, incontrast to the manner in which other notifications are provided, e.g.,in a ‘female’ voice) than the notifications provided with respect to theprior navigation operations. Additionally, in certain implementations adegree to which the operation is relatively unlikely to be complied withcan be determined (such as in a manner described herein) and, based onthe degree to which the operations is relatively unlikely to be compliedwith, at least one of the one or more interfaces at which to provide theone or more operations can be selected (for example, one interface—e.g.,an audio interface—can be selected if the operation is highly unlikelyto be complied with, while another interface—e.g., a visualinterface—can be selected if the operation is relatively less unlikelyto be complied with). Moreover, in certain implementations a degree towhich the operation is relatively unlikely to be complied with can bedetermined and, based on the degree to which the navigation instructionis relatively unlikely to be complied with, the operations can beprovided in a manner that is relatively more prominent than one or moreother notifications provided with respect to the one or more priornavigation operations (for example, with respect to an operation that ishighly unlikely to be complied with, the navigation instruction can beprovided in a highly prominent manner—e.g., considerably louder thanother instructions during the trip—while with respect to an operationthat is relatively less unlikely to be complied with, the navigationinstruction can be provided in a relatively less prominent manner—e.g.,only somewhat louder than other instructions during the trip).

Moreover, in certain implementations the referenced operations can begenerated and/or provided based on the degree to which the operation isrelatively unlikely to be complied with (such as is determined in amanner described herein). Additionally, in certain implementations oneor more interfaces at which to provide the referenced operations can beselected, such as based on the degree to which the operation isrelatively unlikely to be complied with. Moreover, in certainimplementations the referenced operations can be modified, such as basedon/in relation to the degree to which the operation is relativelyunlikely to be complied with (e.g., by adjusting (a) the volume state ofthe device, (b) a volume state of an application executing on thedevice, (c) a display state of the device, (d) a display state of anapplication executing on the device, (e) a haptic state of the device,and/or (f) a haptic state of an application executing on the device).Additionally, in certain implementations the referenced notificationscan be provided to a device associated with a second vehicle. Suchoperations can reflect, for example, that a first vehicle is relativelyless likely to comply with a particular operation. Additionally, incertain implementations one or more vehicle functionalities can beinitiated, such as based on a degree to which the operation isrelatively unlikely to be complied with (e.g., activating a left-turnlane-change mechanism in the vehicle based on a determination that thedriver is unlikely to comply with a left-turn operation). In certainimplementations, the referenced operations can be provided in relationto one or more second devices. In certain implementations, such seconddevices can be/include one or more of the first devices, while in otherimplementations the referenced first devices can be/include one or moreof the second devices. It should also be understood that, in certainimplementations, the device state referenced herein can include a volumestate of the referenced second device(s), a volume state of anapplication executing on the second device(s), a display state of thesecond device(s), a display state of an application executing on thesecond device(s), a haptic state of at least one of the seconddevice(s), and/or a haptic state of an application executing on at leastone of the one or more second devices. As noted, in certainimplementations the one or more first devices can include at least oneof the one or more second devices and/or the one or more second devicescan include at least one of the one or more first devices.

Additionally, in certain implementations information pertaining to adetermination that the alternative set of navigational operations islikely to be less habitual to a user than the first set of navigationaloperations can be provided. Additionally, in certain implementations,information pertaining to a determination that, based on (a) the firstset of navigational operations and/or (b) the alternative set ofnavigational operations, that the alternative set of navigationaloperations is relatively unlikely to be complied with, can be provided.

Moreover, in certain implementations operations/instructions included inthe alternative set of navigational operations that do not deviate fromthe first set of navigational operations can be prevented from beingprovided or not provided (e.g., via one or more interfaces).

Additionally, in certain implementations one or more correctiveoperations can be provided. In certain implementations, such correctiveoperations can be provided based on/in response to a determination thatthe one or more operations included in the alternative set ofnavigational operations are not likely being complied with. Moreover, incertain implementations the referenced one or more operations can beprovided or emphasized based on a device state of a device (e.g., in ascenario in which the audio and/or display of the device is off, such asis described herein.

Moreover, in certain implementations, instead of providing one or moreoperations, the referenced one or more of the one or more operationsincluded in the either set of operations may not be provided, such aswhen the alternative set of navigational operations do not deviate fromthe first set of navigational operations. Additionally, in certainimplementations, the one or more operations included in the either setor both sets of operations may not be provided when the alternative setof navigational operations do not deviate from the first set ofnavigational operations.

Additionally, in certain implementations one or more navigationinstructions can be generated, such as based on the one or more of theone or more operations included in the alternative set of navigationaloperations that deviate from the first set of navigational operationsand a corresponding one or more operations from at the first set ofnavigational operations from which the one or more of the one or moreoperations included in the alternative set of navigational operationsdeviate. Such one or more navigation instructions can be provided inrelation to one or more locations, such as locations associated with theone or more of the one or more operations included in the alternativeset of navigational operations that deviate from the first set ofnavigational operations.

Moreover, in certain implementations the referenced one or morenavigation instructions can include a positive/affirmative instruction(e.g., an instruction that instructs a user to perform the one or moreof the one or more operations included in the alternative set ofnavigational operations that deviate from the first set of navigationaloperations) and a negative instruction (such as an instruction thatinstructs a user not to perform the one or more operations from at thefirst set of navigational operations from which the one or more of theone or more operations included in the alternative set of navigationaloperations deviate).

Additionally, in certain implementations, one or more of the one or moreoperations included in the alternative set of navigational operationsthat deviate from the first set of navigational operations can beprovided in relation to the device (e.g., the device with respect towhich the previously traveled navigational operations areidentified/received).

At 6750, a providing of the first set of navigational operations can beprecluded or otherwise suppressed (e.g., prevented from beingprovided/presented), such as based on a determination that thealternative set of navigational operations is likely to be moreefficient than the first set of navigational operations or based on thefact that the user is already familiar with them and presenting them maybe perceived as unnecessary/annoying.

By way of further illustration, in certain implementations, a navigationapplication can generate and/or provide a more general negativeinstruction reflecting that the route that a user travels regularly (orthe usually optimal route) is not the best route to take during thecurrent trip (or a trip that is scheduled to happen). Such importantinformation can be conveyed explicitly to the user through one of theinterfaces of the device and/or conveyed implicitly to the user (e.g.,by showing a list of current/expected travel times via different routes,in which the usual route is emphasized as being sub-optimal and/or usedas a basis for comparison).

Mobile and fixed in-vehicle navigation applications that providenavigation instructions that are obvious to a user are often consideredannoying. Such instructions interfere with in-vehicle or extra-vehicleconversations, with driver thoughts and create distraction. When adriver is on a route that is known to him (e.g., home to work, work tohome), it can be advantageous to allow the driver to choose to bealerted to only those instructions (and/or only via certain interfaces(e.g., audio, visual, haptic)), if any, which suggest to the driver todeviate from the normally optimal route or the route that the drivernormally takes. Such instructions to deviate from a normally optimalroute can begin with a “negative” instruction (explicit or implicit) andbe followed by additional “positive” or “affirmative” instructions.

For example, on the way to work a user may have 12 turns to make beforehe reaches a critical 13th turn where it is usually better to turn leftand get on highway I-80, but sometimes better to turn right and proceedon highway I-82. Using existing navigation applications, the user might(a) turn on the application at or before the trip start and hear thefirst 12 turn instructions, unnecessarily; or (b) try to remember toturn on the application closer to the critical 13th turn, hoping not toforget and hoping not to lose focus on the driving task while doing so.The techniques described herein can enable the driver to turn on anavigation application before starting the vehicle (or any time after),not have to hear the first 12 instructions and receive the criticalinformation related to the 13th turn.

In certain implementations, certain instructions (e.g., “obvious”instructions) can be suppressed in scenarios in which certain conditionsare determined to be met. For example, if a user was engaged in aconversation (e.g., telephone call, with another occupant) at (oraround) the time that a navigation instruction is to be provided (e.g.,by a navigation application) and that instruction can be determined notto be important (or not important above a certain threshold, such as ina scenario where such an instruction is routine for the user and it ishighly likely that the user will comply with the instruction even if itis not provided), such an instruction can be partially (e.g., itsinterference can be reduced on one interface, for example an audioinstruction can be shortened or made quieter and/or suppressed on onlysome interfaces, for example, the audio part of the instruction can besuppressed while the visual part of the instruction is not) or fullysuppressed (i.e., on all interfaces, e.g., audio, visual, etc.) oraltered (e.g., transitioned from an audio interface to a visualinterface, so that it the instruction interferes less with the ongoingconversation).

In certain implementations, opportunities (e.g. for the presentation ofadvertisements, discount coupons, etc.) and/or advertisements can begenerated and/or presented at a device based on a determination of theoccurrence of one or more events (e.g., trip start, trip end, speed,trip length, etc.). In contrast to traditional location basedadvertising, such a technique can use information related to a user'strip to determine when (or what) to provide advertising and/orcommercial offers. Determinations as to which of several opportunitiesto present the user can be made based on/in relation to the determinedlocation, mode of transportation, time of day, day of week, frequency ofuser visitation to location and/or user preferences. For example, when atrip end is detected at 8:00 AM, a user can be presented with a discountcoupon for breakfast. In another example, three hours into the user'sbicycle ride, s/he can be offered coupon of a local convenience store topurchase a snack (e.g., a ‘PowerBar’).

Moreover, in certain implementations directions/instructions provided bySatNav applications to users (e.g., “turn right at the nextintersection,” etc.) that are actually confusing/ineffective/suboptimalcan be determined/discovered. For example, such directions/instructions(e.g., the audio and/or visual prompts that are provided to users whiletraveling) can be associated with corresponding user actions, such asthose that are performed concurrent with/subsequent to the providing ofsuch instructions. Upon determining that concurrent with and/orsubsequent to the proving of a particular directions/instruction (or setof directions/instructions) by a SatNav application, one or more users(e.g., relatively more users than is typical/average) can be determinedto navigate in a manner that deviates from the instructions provided bythe application (as can be determined, for example, as an instance of‘rerouting’ by the application, for example based on the user making a‘wrong turn’), it can be further determined that such adirection/instruction is relatively likely to be confusing/unclear tousers, and such a direction/instruction can be flagged for improvementand/or provided to the appropriate road authorities in charge, forexample, to evaluate/change the signage, evaluate/change theinfrastructure, etc. Moreover, in certain implementations havingidentified such locations, instructions, operations, etc., as beingrelatively confusing, unclear, etc., a ‘special instruction’ can begenerated and provided, such as in a manner described herein, such aswith respect to FIGS. 80-85 and 98. For example, a notification such as“Be careful! You are approaching a tricky location at which many peoplemake errors. In 400 m you must turn left—be careful not to take thetunnel” can be generated and provided. Additionally, in certainimplementations such an instruction/notification can be provided via oneor more interfaces, at a different intensity, etc., such as in themanner described herein.

FIG. 60 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 6010, one or more first time intervals can be received. In certainimplementations, such time intervals can correspond to an amount of time(e.g., in hours, minutes, second, etc.) that a trip (e.g., between anorigin and a destination) was/is determined to actually have taken(e.g., an actual trip time/duration). Moreover, in certainimplementations, each of the referenced time intervals can correspond toone or more respective first navigation instances between an origin anda destination that are associated with a first navigation instructionprovider. Such a navigation instruction provider can be, for example, anavigation application that is directed to assisting user in navigating(e.g., driving) from an origin to a destination by generating andproviding a series of navigation instructions (e.g., drivingdirections). Moreover, in certain implementations one or more first tripefficiency metrics can be received. Examples of such trip efficiencymetrics include but are not limited to a distance (e.g.,miles/kilometers traveled), a fuel efficiency metric (e.g., amount ofgas or electricity expended), a time interval (e.g., a number ofminutes/hours), and/or any other such metric or quantity that canreflect or quantify one or more aspects associated with a trip.

At 6020, one or more second time intervals can be received. In certainimplementations, each of the referenced second time intervals cancorrespond to one or more respective second navigation instances betweenthe origin and the destination (e.g., substantially the sameorigin/destination that are associated with the first navigationinstances referenced at 6010). Moreover, in certain implementations thereferenced first time intervals and the second time intervals maycorrespond to one or more substantially similar trip characteristics(e.g., the same/substantially similar day, date, time of day, trafficcondition, etc.). Doing so can ensure that the comparison between firsttime interval(s) and the second time interval(s) accurately reflectdifferences in efficiency (as opposed to, say, different trafficpatterns at different times of the day). Moreover, in certainimplementations, the referenced one or more respective second navigationinstances can include one or more respective second navigation instancesbetween the origin and the destination (e.g., substantially the sameorigin/destination that are associated with the first navigationinstances referenced at 6010) that are associated with a secondnavigation instruction provider (e.g., a navigation application/providerother than the application/provider associated with the one or morefirst time intervals, or, alternatively, the same navigationapplication/provider configured with different settings—e.g., a settingto avoid/use toll roads, highways, to compute instructions based on fuelefficiency as opposed to time efficiency, etc.). Additionally, incertain implementations the referenced second navigation instance maynot be associated with a navigation instruction provider (e.g., in ascenario in which a user is simply driving without the user of anavigation instruction provider). Moreover, in certain implementationsone or more second trip efficiency metrics can be received (e.g., withrespect to distance, fuel efficiency, etc.).

It should be noted that multiple instances of the referenced first andsecond time intervals can be received over time, and, in doing so adatabase can be generated which contains historical informationpertaining to time intervals with respect to variousorigins/destinations, at various times/conditions, with respect tovarious navigation instruction providers, etc. (e.g., usingcrowdsourcing techniques as are known to those of ordinary skill in theart). Based on such aggregated information, the various comparisons anddeterminations described herein can be made, such as with respect tonumerous time intervals that have been observed/identified.

At 6030, the one or more first time intervals (such as those received at6010) can be compared with the one or more second time intervals (suchas those received at 6020). In doing so, a relative efficiency of thefirst navigation provider can be determined, such as in a mannerdescribed herein. Moreover, in certain implementations the one or morefirst time intervals (such as those received at 6010) can be comparedwith the one or more second time intervals (such as those received at6020) to determine which of the first navigation instruction provider orthe second navigation instruction provider provide navigationinstructions that correspond to a relatively lower time interval (and/oris otherwise more efficient, such as based on any number of otherfactors such as fuel efficiency, distance traveled, etc.). Additionally,in certain implementations the one or more first efficiency metrics(such as those received at 6010) can be compared with the one or moresecond efficiency metrics (such as those received at 6020) to determinea relative efficiency of the first navigation provider (e.g., withrespect to the efficiency metric, e.g., fuel efficiency, distancetraveled, etc.).

At 6040, a recommendation can be provided. In certain implementations,such a recommendation can be to select the first navigation instructionprovider. Moreover, in certain implementations such a recommendation(e.g., to select the first navigation instruction provider togenerate/provide further instructions) can be provided based on adetermination that the first navigation instruction provider isrelatively efficient (e.g., with respect to distance, fuel efficiency,time, etc.—for example, based on a determination that the firstnavigation instruction provider provides navigation instructions thatcorrespond to relatively lower time intervals). Moreover, in certainimplementations the referenced recommendation (e.g., to select the firstnavigation instruction provider) can be provided with respect to ageographic location (e.g., in response to a request for navigationinstructions that can be determined to originate from and/or correspondto a destination associated with the same or a substantially similar orrelated geographic location). Additionally, in certain implementationsthe referenced recommendation to select the first navigation instructionprovider can be provided with respect to the origin and/or thedestination (e.g., ‘select navigation application X for trips startingin New York City,’ ‘select navigation application Y when traveling toBoston,’ ‘select navigation application Z when traveling from New YorkCity to Boston,’ etc.). Moreover, in yet other implementations one ormore actions can be initiated (e.g., based on a determination that thefirst navigation instruction provider is relatively efficient). Forexample, a device (e.g., smartphone) can be configured to select fromamong several available navigation applications based on a determinationthat a particular application is more efficient than the other(s) (e.g.,navigation application X can be automatically selected for trips in NewYork City while navigation application Y can be automatically selectedfor trips in Boston). By way of illustration, it can be advantageous todetermine and be able to notify users as to various efficiencies (e.g.,time savings) with respect to which they are likely to benefit (or havebenefitted) by using a particular navigation application (e.g., asatellite navigation or ‘SatNav’ application). Doing so can, forexample, enable users to make smarter “purchasing” decisions as to whichapplications and/or premium features to choose, such as by consideringthe costs of such applications/features against their benefits.

The benefits (e.g. time savings, fuel savings, safety gains) of anavigation application (for a navigation provider and/or to a navigationuser) can be quantified or otherwise determined, for example, by (a) oneor more navigation providers where each such provider effects its owncalculations, e.g., according to particular standards or protocols (withor without independent auditing) so that the results can be comparedeasily across providers or (b) a central server/system which computes,scores, and/or ranks various statistics related to the benefits providedby various providers, thereby allowing a user to compare moreeffectively across/between providers.

For example, a technique for calculating the benefits that a navigationapplication's route choice offers its user relative to another route(e.g., the main line/straightforward route or the usual/common route atthat point in time) to the same location can be computed by comparing(i) the time that it takes a user that travels from Origin A toDestination B on the route recommended by a navigation application with(ii) the time that it takes for a different user (who may or may not beusing the same navigation application or any navigation application atall), that travels from Origin A to Destination B along a differentroute, starting at substantially the same time. Such acomputation/comparison can be done on a trip-by-trip basis and/or acumulative basis, e.g., over some period of time (e.g., day, week,month, since installed) and can, in certain implementations, be furthercontrolled for respective driving styles (e.g., certain drivers maynaturally driver faster than others) and can also use variousstatistical noise reduction techniques to meaningfully aggregateinformation across users, across routes and across time. For example, ifa user who, on average, drives at a speed that is 2% slower than theaverage, drives three trips from Origin A to Destination B, followingthe recommendation of the navigation application each time (whichrecommendations happened to include identical navigation instructionseach time), which trips take 40 min, 45 min and 50 min each,respectively, whereas 1,000 other drives from Origin A to Destination Bthat occurred at substantially the same time (e.g., they began theirtrip at within 10 seconds of the time the user began her trip) alongdifferent routes took an average (across devices) of 42 min, 47 min and52 min each, where the average speed at which the (1,000 or fewer)drivers of these 1,000 drives is 0% slower than the average, and so, thenavigation application used by the mobile device provided a benefits ofabout 3 minutes per trip (˜7% per trip), on average, for that user. Thisinformation can also be aggregated across multiple users of the samenavigation application, across multiple days to determine/score thebenefits of the application, and the same can be done for multiplenavigation applications, so that comparison statistics between differentnavigation applications can be generated/provided (reflecting which oneprovides instructions that are most time efficient, fuel efficient,etc.).

It should be understood that when analyzing trips that begin at Origin Aand end at Destination B, this does not necessarily connote that thetrip actually began and ended at these locations (i.e., that the enginewas ignited at Origin A and the engine was turned off at Destination B).Rather, travel/a trip between the referenced ‘Origin’ and ‘Destination’(as they are used/referenced herein) can refer to the device travelingfrom Origin A to Destination B without user-elected stops (e.g., at agas station). Accordingly, it can be appreciated that any tripundertaken by the user may consist of any number of (potentiallyoverlapping) segments that can be used for the purposes of calculatingthe benefits and the navigation application scoring described herein.

FIG. 61 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 6110, one or more first navigation instructions can be received. Incertain implementations, such instructions can be received from a firstprovider. Moreover, in certain implementations such instructions canpertain to a particular destination.

At 6120, one or more second navigation instructions can be received. Incertain implementations, such instructions can be received from a secondprovider. Moreover, in certain implementations such instructions canpertain to a particular destination (e.g., the same or substantiallysimilar destination to the instructions received at 6110).

At 6130, the first navigation instructions (e.g., those received at6110) can be compared with the second navigation instructions (e.g.,those received at 6120). In doing so, it can be determined which of thefirst navigation instructions or the second navigation instructions arerelatively more efficient (e.g., with respect to time, fuel efficiency,distance, etc.).

At 6140, a recommended set of navigation instructions can be provided.In certain implementations, such a recommended set of navigationinstructions can be provided based on the relative efficiency (e.g., asdetermined at 6130). In certain implementations, the referenced relativeefficiency can include or reflect a relatively shorter distance, arelatively shorter timeframe. a relatively lower fuel expenditure, etc.

At 6150, a deviation from the recommended set of navigation instructionscan be identified (e.g., at a point along a trip where a user deviatesfrom the recommended set of navigation instructions), and, based on anidentification of the deviation from the recommended set of navigationinstructions, a relative efficiency of the recommended set of navigationinstructions in relation to the deviation can be computed (reflecting,for example, an amount of time, gas, etc., that the user is likely tohave saved had they followed the recommended set of navigationinstructions and not deviated therefrom).

At 6160, a notification corresponding to the relative efficiency (e.g.,of the recommended set of navigation instructions in relation to thedeviation therefrom) can be provided (e.g., “following the instructionsprovided by navigation application X would have saved you 5 minutes overthe route that you are taking”).

FIG. 62 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 6210, an estimated travel duration can be received. In certainimplementations, such an estimated travel duration can be received withrespect to one or more first navigation instructions (e.g., from anorigin and/or to a destination)

At 6220, an actual travel duration can be compared with respect to theone or more first navigation instructions to the destination. In doingso, an accuracy of the estimated travel duration (e.g., the estimatedtravel duration received at 6210) can be determined.

FIG. 63 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 6310, a suggestion of one or more first navigation instructions to adestination can be provided. In certain implementations, such asuggestion can be provided based on an estimated travel duration, suchas with respect to one or more first navigation instructions to thedestination (and/or from an origin to the destination).

At 6320, an actual travel duration can be determined. In certainimplementations, such an actual travel duration can be determined withrespect to one or more second navigation instructions, such as one ormore second navigation instructions to the destination.

At 6330, a relative efficiency of the one or more first navigationinstructions can be determined. In certain implementations, such arelative efficiency of the one or more first navigation instructions canbe determined by comparing an actual travel duration with respect to theone or more first navigation instructions to the destination with theactual travel duration with respect to one or more second navigationinstructions to the destination.

FIG. 64 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 6410, one or more eligibility characteristics can be determined. Incertain implementations, such eligibility characteristics can bedetermined with respect to a navigational instance (e.g., an incidenceof a trip, such as from one geographic location to another). In certainimplementations, the referenced eligibility characteristics can includebut are not limited to: a quantity of occupants within a vehicle, a timeand/or date, a vehicle class, and/or a vehicle weight.

At 6420, one or more navigational instructions can be computed. Incertain implementations, such navigational instructions can be computedbased on the one or more eligibility characteristics (such as thosedetermined at 6410).

For example, in a scenario in which the referenced eligibilitycharacteristics pertain to a quantity of occupants within a vehicle, thereferenced navigational instructions can be computed based on thequantity of occupants within the vehicle. In a scenario in which thereferenced eligibility characteristics pertain to at a time and/or date,the referenced navigational instructions can be computed based on thetime and/or date. In a scenario in which the referenced eligibilitycharacteristics pertain to a vehicle class and the referencednavigational instructions can be computed based on the vehicle class. Ina scenario in which the referenced eligibility characteristics pertainto a vehicle weight, the referenced navigational instructions can becomputed based on the vehicle weight.

At 6430, the one or more navigational instructions (e.g., those computedat 6420) can be provided (e.g., within/in conjunction with a navigationapplication).

At 6440, a change can be identified. In certain implementations, such achange can be identified with respect to the referenced eligibilitycharacteristics (such as those determined at 6410). For example, it canbe determined (e.g., based on seat sensors, etc.) that a vehicle thatpreviously had three passengers riding in it now has only one).

At 6450, the one or more navigational instructions can be recomputed. Incertain implementations, such instructions can be recomputed based onthe changed eligibility characteristics (e.g., as identified at 6440).For example, having determined that fewer passengers are in a vehiclethan were previously (and thus the vehicle no longer qualifies to travelin the ‘carpool lane,’ navigation instructions (e.g., to a destination)can be recomputed to account for the fact that the vehicle can no longertravel in the ‘carpool lane.’

In certain implementations, a navigation application (e.g., anapplication that determines the optimal route to travel between two ormore locations) can be configured to account for the eligibility of aparticular vehicle (i.e., the vehicle within which the user istraveling) to travel in restricted (e.g., carpool) lanes, restrictedroads, etc., and to improve the computation of such optimal routesconditioned on such information. For example, the eligibility of avehicle to travel in certain lanes or on certain roads may depend on/bea function of the number of occupants within the vehicle (e.g., forcarpool lanes, mass transportation lanes, etc.), the time of day and/orday of week (e.g., right turns on red may be allowed or prohibitedbetween certain hours or on certain days), vehicle weight (e.g., roadslimited to vehicles weighing fewer than 5 tons), the vehicle class(e.g., trucks must drive in two right lanes only, may not travel oncertain streets, highways, bridges, etc.), and, using the varioustechniques described herein (e.g., to determine the number of passengerswithin a vehicle, the vehicle class, etc.), a navigation application canaccount for such determinations and compute/adjust the routing to aparticular destination accordingly. Additionally, in certainimplementations the eligibility of a particular vehicle may changedynamically over the course of a journey (e.g., occupants may enter orexit the vehicle, cargo can be loaded or unloaded, a time/date range canbe entered or exited, etc.), and thus the navigation application canrecompute the referenced routing at the occurrence of various events(e.g., stops), at various intervals and/or on an ongoing basis and, insome cases, e.g., when they receive an advance schedule of stops andpick-ups with occupants and/or cargo weight, take such factors intoaccount in advance. In certain implementations one or more of theparameters that are considered in determining such an improved optimalroute may be conveyed/provided/input manually (e.g., user input viatouch, voice, gesture) and/or electronically (e.g., by communication,directly or indirectly, with a vehicle's systems (e.g., weight sensors,heat sensors, seat belt sensors, etc.)) or remotely (e.g., factory loadsweight data provided over the air) or set as defaults.

In another embodiment, a navigation application offers an emergency modewherein the determination of an optimal route for a vehicle to travelbetween two or more locations might be made assuming that it is eligibleto travel in all lanes (and on all roads) regardless of the restrictionsthat would ordinarily be applicable to such vehicle in non-emergencycircumstances.

Various other types of lane/road restrictions are also possible, such astravel restrictions on certain types of vehicles. For example, certaintravel priorities (e.g., specific lanes, roads, traffic rules, etc.) maybe provided to: (a) pollution friendly vehicles, e.g., hybrid orelectric vehicles (as opposed to pollution unfriendly vehicles); (b)vehicles equipped with one or more safety features (as opposed tovehicles not so equipped); and/or (c) autonomous vehicles (as opposed tonon-autonomous vehicles).

In another implementation, the flow of traffic (e.g., forecasted,real-time, historical, and/or static) can also be utilized as an inputand/or otherwise factored/accounted for by/in conjunction with anavigation application routing system with respect to differentiatingbetween the flow of traffic in different lanes (or on different roads),based upon the conditions required for a vehicle to be eligible totravel in such lanes (or on such roads). For example, lanes with respectto which only vehicles that meet one or more conditions (e.g., more than3 occupants) are permitted can be accounted for (e.g., by the navigationapplication) as different/separate roads and computing a routing to aparticular destination can account for the fact that eligible vehicleshave the option of traveling in both such restricted lanes (or roads) aswell as in unrestricted lanes, while also accounting for the fact thatineligible vehicles (e.g., those having fewer than 3 occupants) may onlytravel in unrestricted lanes (i.e., they have more limited routingpossibilities).

In another implementation, traffic crashes and/or other incidents thatare reported on roads (e.g., by crowdsourcing), are expanded to includethe side of the road on which (or lane(s) in which) the crash took place(or in which immobile vehicles are blocking traffic). Doing so canassist drivers by alerting them to the lanes they should move into inorder to pass the blockage and can also significantly improve routingsystems such as those described herein (e.g., if the crash is known tohave taken place in an unrestricted lane, vehicles eligible for thecarpool lanes are likely to be significantly less-effected by the crashthan vehicles that are not eligible for the carpool lanes, or, forexample, if the crash took place in the right lane of a 6-lane road, atruck that is only allowed to travel in the two rights lanes is likelyto be relatively more delayed by the crash than a passenger vehicle thatis eligible to travel in all 6 lanes).

FIG. 65 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 6510, a degree of danger can be computed. In certain implementations,such a degree of danger can be computed with respect to a navigationalinstance (e.g., an occurrence of trip, such as between one location andanother, which, in certain implementations, may be guided viainstructions originating from a navigation instruction application). Incertain implementations, the referenced the degree of danger can becomputed based on: a speed limit associated with the navigationalinstance, a road curvature associated with the navigational instance,one or more weather conditions associated with the navigationalinstance, a time associated with the navigational instance, a date orday of week associated with the navigational instance, a skill level ofa driver associated with the navigational instance, a driving history ofone or more drivers associated with the navigational instance, one ormore driving tendencies of a driver associated with the navigationalinstance, one or more incidents associated with one or more driversassociated with a location within the navigational instance, one or moreincidents associated with a location within the navigational instance,and/or a vehicle type associated with the navigational instance (it canbe appreciated that data pertaining to some or all of such factors may,for example, dictate or suggest the degree of danger associated withtraveling with respect to a particular route, at a particular time, by aparticular driver driving a particular vehicle under specificconditions). Moreover, in certain implementations a determination of anentry of a vehicle into a relatively dangerous location can also becomputed.

Additionally, in certain implementations one or more sets of navigationroutes can be computed, such as between an origin and a destination. Incertain implementations, such sets of navigation routes may be beingassociated with respective degrees of danger (e.g., route X is twice asdangerous as route Y, such as with respect to a particular driver at aparticular time and/or under particular conditions).

At 6520, one or more actions can be initiated. In certainimplementations, such actions can be initiated based on a degree ofdanger (such as is computed at 6510). For example, in certainimplementations, one or more notifications can be provided inconjunction with the entry of a vehicle into the relatively dangerouslocation (e.g., a warning that can be provided to the driver that theyare entering a dangerous driving location, which, in certainimplementations, may also include information pertaining to thenature/cause of such danger and/or suggestions as to what the driver cando/how the driver can drive to minimize such danger). Additionally,various aspects of the functionality of one or more crash avoidancetechniques or technologies (e.g., as may be implemented or integratedwithin the vehicle, such as automatic braking or steering technologies)may be initiated, modified and/or removed based on the computed degreeof danger. It should be understood that, in certain implementations, theoperation of such crash avoidance techniques/technologies may beaffected by instructions originating from systems/application thatpertain to navigation during the navigation instance (e.g., a navigationinstruction application).

Moreover, in certain implementations, one or more sets of navigationinstructions can be recommended (e.g., by a navigation instructionapplication) based on their respective degrees of danger (e.g., anavigation instruction provider can indicate or notify a user of therespective degrees of danger associated with each potential route/set ofinstructions, and/or can suggest a particular route/set of instructionsbased on its relative or absolute degree of danger). Additionally, incertain implementations one or more third-party incentives can beprovided with respect to one or more of the sets of navigationinstructions based on their respective degrees of danger (for example,an insurance company can provide the user with an incentive—e.g., ‘save$3 off your insurance premium’—in return for the user selecting aparticular route/set of instructions that is determined to be relativelyless dangerous than other options).

By way of further illustration, it can be appreciated that differentroads can be identified/determined to be associated with different typesof and/or different levels of danger. Such danger types and/or levelscan be estimated (e.g., based on speed limit, road curvature, surface,presence/absence of guard rails, current, predicted, and/or historicalweather conditions, etc.) and/or measured/determined empirically (e.g.,based on a number of fatalities, injuries or crashes on a stretch ofroad) and can further be normalized in various ways (e.g., number ofvehicle trips, time of day, day of week, time of year, type of vehiclespermitted/traveling, etc.).

Information about the danger level of a road can be utilized,considered, factored in, etc., in various ways. For example, in oneimplementation, upon determining that a vehicle is entering (or leaving)a dangerous stretch of road, one or more warnings, notifications, etc.,(e.g., audio, visual, haptic) can be generated and provided to a driver,such as through one or more interfaces (e.g., a mobile device, aninfotainment system, a steering wheel, etc.). In another implementation,the operation/behavior of one or more vehicle/driver safety accessoriescan be configured to change based on such road danger information. Forexample, upon identifying/determining that a vehicle is entering a highroad danger area, parameters of a crash avoidance system can bechanged/modified (e.g., temporarily), such as parameters that definetailgating so as to generate/provide recommendations to the driver tomaintain more distance between the vehicle being driven and the vehiclein front of it.

In certain implementations, a navigation application can be configuredto compute a route from one location to another in a manner thatoptimizes/accounts for the safety of the route, with or without otherterms/factors (e.g., estimated time to destination, variance of time todestination, cost to destination, etc.). In another implementation, theoptimal route(s) can be determined subject to satisfying certainconstraints/requirements, one or more of which can pertain to the safetyof the route, e.g., compute the fastest route, subject to not travelingon any extremely dangerous roads. In another implementation, anavigation application can be configured to generate/provide/recommenddifferent routes for different drivers based on each driver's respectivelevels of experience, characteristics, skill, driving tendencies, etc.(as can be determined, computed, observed, etc.) based on one or morefactors (e.g., danger, length, time of day, etc.). For example, (i) theroutes recommended to a young driver may be different than thoserecommended to a more experienced driver; (ii) the routes recommendedfor daytime driving from destination A to destination B may be differentthan those recommended for night time driving from A to B (even whenthere are not time related differences).

In another implementation, insurance companies and/or other entities(e.g., regulatory agencies) can incentivize/encourage/require theirpolicyholders to place more weight/emphasis on the safety of their routeselections and/or to dis-incentivize those policyholders that do not,such as by reducing (or penalizing) drivers (or vehicles) based on theroutes they traveled. For example, instead of a customer paying herinsurance company a fixed fee (e.g., annually) or paying based upon howmuch she drives (e.g., distance, time), she would now pay, in part or inwhole, based upon the safety of the routes on which she chooses to driveon. Such incentives could also be computed based on a combination offactors (e.g., safety and age/experience/skill), for example, youngdriver might pay a disproportionately higher price (or not be insured atall) when traveling, for example, on certain dangerous roads and atcertain times.

It should be noted that, in certain implementations, dangerousgeographical locations that are not directly related to road safety(e.g., dangerous neighborhoods, war zones, dangerous to people from onesocio-economic-political affiliation) may also be accounted for in thedescribed techniques.

While some of the examples and illustrations provided herein may havebeen described with respect to a mobile device(s), it should beunderstood that many or all of them may be equally applicable tonon-mobile, in-vehicle interfaces (e.g., infotainment systems,navigation systems, etc.) and vehicle-to-vehicle systems (“V2V”) andvehicle-to-infrastructure systems (“V2I”) as well.

In certain implementations, various aspects of a vehicle's behavior inturns and around corners can be determined (e.g., scored, measured)using a mobile device (or a non-nomadic device) and informationregarding that behavior can be delivered/used by various parties (e.g.,as feedback to the driver, to the driver's employer or parents, to aninsurance company). In one implementation, the acceleration (e.g., asperceived by the device's accelerometer) can be correlated to the turn(e.g., as perceived using the GPS radio on the device in conjunctionwith a map). The acceleration perceived by the device will tend tochange in a turn both on one or more axes (depending on the orientationof the device with respect to the vehicle) and/or overall (e.g., theroot mean square or the root mean delta square of the 3-axisaccelerometer values). The GPS lag, i.e., the time it takes for a changein speed in a vehicle to be perceived and reported by the GPS radio on adevice in the vehicle can also be used to better correlate betweenacceleration (or changes in acceleration) and the road topography.

FIG. 37 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3705 a plurality of indications can bereceived. In certain implementations, each of the one or moreindications can correspond to at least one of: (a) a determination of astart of a trip or (b) a determination of an end of a trip. At 3710, arequest for a vacant parking location can be received. At 3715, theplurality of indications can be processed, such as in order to identifyone or more vacant parking locations. At 3720, a notificationcorresponding to at least one of the one or more vacant parkinglocations can be provided. In certain implementations, such anotification can be provided in response to the request.

A trip can be determined to have ended when a driver parks a vehicle anda trip typically starts when a driver starts a parked vehicle.Accordingly, it can be advantageous to determined and/or maintainparking information related to vehicles (e.g., where vehicles areparked, how long they have been parked, their parking habits, when theyvacate their parked position, etc.). Moreover, based on suchinformation, technologies can be implemented whereby vehicles that seekto park in an approximate particular location can be provided with toolsto assist them to do so more effectively/efficiently (e.g., faster, withless stress, cheaper, with better alignment between parkingrules/regulations and their needs, etc.).

For example, in certain implementations, information related to publicparking regulations can be obtained/referenced, such as from a database(built, for example, via crowd-sourcing). Accordingly, upondetermining/detecting a ‘trip-end’ (i.e., the end of a trip, such as inthe manner described herein) at/in relation to a mobile device, it canalso be determined that a vehicle may have parked in that location. Suchdetermination(s) can be computed with even greater accuracy, forexample, based on a determination that the device with respect to whichsuch determinations are made has also been determined to be operated bya user identified as a driver. By way of further example, when a mobiledevice determines/detects a ‘trip-start’ (i.e., the start of a trip,such as in the manner described herein) it can also be determined that avehicle that was parked in that location is likely to have vacated aparking spot.

In one implementation, users that are determined to be leaving theirparking location (e.g., as determined, for example, through the use ofone or more trip start/end determination techniques, such as thosedescribed herein, and/or through the use of a parking paymentapplication such as Pango) can be offered a reward (e.g., a parkingdiscount, cash, credit for future parking, credit or discount from a3^(rd) party, etc.) to remain in their current location for a someperiod of time, until a certain other vehicle can arrives in order toallow the parking spot to be ‘handed off’ or transferred from one userto the other. Moreover, in certain implementations, users that arelooking for parking spaces can be offered the opportunity to receive (orreserve) a parking space near their desired location in return forproviding a payment (e.g., in-app, credit card, e-wallet, etc.).

It can be appreciated that such technologies can be configured such thatthe cost (e.g., to the ‘new’ parker) and the payment (e.g., to thecurrent parker) can be static or dynamic (e.g., based on time of day,day of week, day in year, location, number of currently parked users,parking habits of users, etc.).

In one implementation the participation of a user in such a systemand/or the payments and costs thereto can be governed by the user'sreputation, as can be determined based on the user's previoustransactions.

It should also be noted that any or all instructions and/ornotifications referenced herein can be delivered audibly and/or hapticlyand/or visually.

Moreover, any/all of the referenced navigation applications and theimprovements described herein can be implemented client-side (e.g., on adevice such as a mobile device, on an in-vehicle device, on another typeof device, etc.) and/or server-side (i.e., remotely) and/or in acombination of the two.

FIG. 41 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4105 one or more restrictions can beemployed, such as in relation to a user device. In certainimplementations, the one or more restrictions can include a restrictionof one or more messaging services, such as in relation to the userdevice. At 4110, a message associated with a restriction overridenotification can be received. At 4115, it can be determined that themessage originated from one or more designated sources. At 4120, aninstruction can be provided, such as to perform one or more actions. At4125 the message can be provided, such as in relation to the userdevice. In certain implementations, the message can be providedconcurrent with an employment of the one or more restrictions. Incertain implementations, the referenced message can be provided inrelation to the user device, such as based on a determination that theone or more instructions have been performed.

In another embodiment, a third party can ‘page’ a vehicle driver throughthe driver's mobile device. Upon receiving such a ‘page,’ the device cansignal to the driver (e.g., using audio, visual and/or haptic means)that there is an emergency or other such occurrence that the driver mustaddress (in certain implementations by first stopping or slowing downthe vehicle). Such techniques can be useful in scenarios where a deviceoperated by a user determined to be likely to be a driver of a vehicleis put into a restricted mode so as to prevent distraction (e.g.,otherwise preventing calls, texts, etc.), because such a ‘page’ canprovide a relatively low distraction manner in which to alert the driverthat they are urgently needed.

It should be noted that such techniques can also be implemented withrespect to devices that are in other forms of “do not disturb” modes,whether they are passenger devices or not even within a vehicle.

In one implementation, such techniques can be employed whereby a partywishing to urgently contact a device user can be provided with a messagefrom the user's device indicating that the device user is currentlydriving and cannot safely communicate. The party can also be notified asto how to ‘page’ the user in urgent situations. Such a notification canbe provided, for example by/in relation to the user's device (e.g., viaa voice message and/or a text message indicating, for example that “I amdriving right now and cannot take your call, if you need my attentionurgently, please [take a certain action]”), and/or via a third party orobject (e.g., as provided by the user's company, the user's spouse, awebsite containing such information, the user's business card, etc.).

Examples of action(s) to be taken by the party wishing to ‘page’ thedevice user include but are not limited to: (i) calling a specifiedtelephone number, (ii) providing a specified code in a voicemail or IVRsystem (either on the device or remotely), (iii) texting to a specialnumber or emailing to a special address or posting to a certain URL/IPaddress, and/or (iv) texting/e-mailing/posting a special message or amessage containing a special code to the user's device. Such techniquescan signal a ‘page’ to the device directly (e.g., via a text message tothe device with a short message such as “page”), and/or indirectly, suchas by causing a ‘page’ to be communicated or signaled to the device(e.g., the party inputs the “page” code on the user's company voice mailmenu (e.g., in response to a prompt indicating that “to reach meurgently hit 4”, which, in some implementations, may be made availableonly based on a determination that the user is driving) and, inresponse, the voice mail program sends a pre-defined signal to theuser's device). It should be understood that the referenced ‘page’signal(s) can be sent/transmitted in various ways, e.g., via voice,data, RF, etc.

Upon receipt of the referenced ‘page’ signal, the driver's device can beconfigured to provide one or more alerts to the driver, such as thosethat indicated that someone is urgently seeking them. Such alerts may beprovided in any of a number of ways, such as, visually (e.g., by causingthe device to turn on and have the screen blink red), via audio (e.g.,by playing an audio file saying “someone is trying to contact youurgently” with or without the name of such person, if available) and/orhaptically (e.g., by providing a special haptic/vibration pattern toindicate a ‘page’).

In certain implementations the referenced paging feature can beconfigured to restrict those that can page a device (e.g., only contactsdetermined to be stored at/in relation to the device), so as to minimizedistraction/potential harassment.

In addition, in various implementations one or more of the variousfunctionalities and features described herein can be provided as optionswhich the user can choose to enable or disabled as desired.

Moreover, in certain implementations the device and/or one or moreapplications executing thereon can be configured to preventuninstallation of one or more applications, such as of one or moreapplications that enable one or more aspects of the variousfunctionalities described herein. For example, in one implementation, afirst application/module can monitor the ongoing execution of a secondapplication/module. Upon determining that the second application is nolonger executing, the first application can initiate thereexecution/reinstallation of the second application. Moreover, incertain implementations a device can be polled (e.g., remotely) toidentify applications that are running/installed on the device. Uponidentifying that a particular application is not installed/running, suchan application can be installed/initiated.

Moreover, in certain implementations one or more of the varioustechnologies described herein can be implemented in scenarios whereidentifying an existence of/interaction with a human user (as opposed toa computer/non-human user) can be advantageous). For example, inscenarios, such as for event ticket purchases, where vendors wish toensure that the purchaser of such items (e.g., tickets) are human users(and not computer ‘bots’ or robots programmed to perform suchtransactions), one or more of the various techniques described hereincan be implemented in conjunction with such a transaction, in order todetermine that the purchaser is likely to be a human user (by virtue ofvarious sensor-based determinations, such as those originating at amobile device, such as is described herein).

It can be appreciated that a tension exists between whether advertisershould pay for ‘leads’ (e.g., using a cost per click model) or‘acquisitions’ (e.g., using a cost per action model). Accordingly, itcan be advantageous to provide techniques/technologies that areoperative to increase the likelihood that award/promotionalpoints/credits that are converted into a discount coupon/voucheractually result in a sale. In doing so, companies that provide suchdiscount coupons can be paid/compensated more based upon the issuance ofthe coupon than is currently prevalent in existing systems/frameworks,avoiding the necessity of receiving subsequent reports from the couponhonoror in order to be paid/compensated. To do this, the time for whichsuch a coupon is valid can be limited (a “time bomb”), and user to whichthe coupon is issued can be required to be within a certain location(e.g., within a certain store) in order to make the conversion thatgenerates the coupon. For example, in order to convert United ‘frequentflyer’ miles into a coupon for a 20% discount at Marriott (for whichUnited gets paid some amount by Marriott), Marriot may wish to requirethat, in order to pay United for the mere conversion of the miles into acoupon (and not through Marriott's subsequent definitive confirmation ofsuch a booking), the customer must make the conversion of the miles intothe coupon within Marriott's hotel grounds (as can be determined viaGPS, WiFi, cell-towers, BT, camera, NFC, and/or any other suchdetermination technique, such as is described herein) and/or thevalidity of the coupon can also be time-limited (e.g., only valid forredemption within the next 15 minutes).

Moreover, in certain implementations vehicle recognition equipment(e.g., cameras) can be oriented in various locations, such as thosewhere driving is inappropriate/illegal (e.g., oriented in locations withrespect to which occurrences such as drivers driving through a gasstation in order to gain a few extra minutes during traffic, cutting inline at a highway exit, etc., can be observed). Using such camera(s),one or more vehicles that perform such inappropriate/illegal acts can beidentified (e.g., using license plate recognition technologies, as areknown to those of ordinary skill in the art). Upon identifying suchvehicles (and/or users associated with such vehicles, such as theregistered owners/drivers of such vehicles), the identity of suchvehicles (and/or users/drivers) can be processed against one or moredata items, data sets, databases, etc., such as those referenced herein,in order to determine whether such vehicles (and/or users/drivers) havehigher rate of crash or insurance claims than the population at large(or the population having one or more similar/comparablecharacteristics, e.g., the same/comparable type of car, and/or in thesame geographic area, etc.). Moreover, in certain implementations thereferenced data and/or determinations can be maintained in a databaseand insurance policies of drivers determined to be exhibiting (or notexhibiting) the same or comparable behaviors can be priced accordingly(e.g., higher or lower).

In certain implementations, various techniques described herein can beemployed in order to protect users against the risks of using theirmobile device(s) while such users are in motion. For example, inindustrial settings (e.g., on manufacturing floors), where employeeswalking or operating industrial equipment (e.g., a forklift, a ladder,etc.), while they are distracted by their mobile device, can cause greatdamage to people and property, and on sidewalks, in stairwells, and onescalators, where pedestrians walking while distracted by their mobiledevice can cause injury and economic loss to themselves and others.

For example, inputs originating from one or more sensors of a mobiledevice can be processed to differentiate (i) movements that areindicative of (a) a user's full body being in motion, relative to earth;or (b) a user's needing to be in full body motion relative to earth inorder to remain in contact with and/or in substantially the sameproximity to the device, and regardless of whether the energy for suchmovement is provided by the user, like walking, swimming or provided byan external source, like riding an elevator, escalator or forklift; from(ii) no movement; from (iii) movements that are indicative of only partof a user's body being in motion, relative to the earth (e.g., holdingphone while bending, standing, waving arms). Uponidentifying/determining a pattern indicative of full body movement amongsuch inputs, one or more restrictions can be employed at/in relation tothe device, e.g., until such time as a pattern that is no longerindicative of full body movement (or, in some cases, of any bodymovement) can be identified/determined at/in relation to the device.

Such techniques can be advantageous, for example, in order to allow adevice operator to interact with a mobile device while standing in alargely fixed location (but in which the device may not be completelymotionless relative to earth), but to restrict the device (such that theoperator prevented/precluded from so interacting with the device in oneor more ways) when walking or operating a forklift. In another example,a device can be configured to enable an employee to place a call on thedevice while standing near a stairwell, but such a device can berestricted such that the employee cannot place the same call once shecan be determined to be engaged in the more dangerous act of walking thestairs.

It should be noted that full body movement can bedetected/determined/identified, for example, by analyzing inputsoriginating at the accelerometer and/or gyroscope of the device todetect a pattern indicative of walking (e.g., steps). From the time thatsuch movement is determined to have started, e.g., until some time afterit is determined to have ended, one or more restrictions (e.g., alockscreen is shown, phone calls are not allowed in our out, etc.) canbe employed at/in relation to the device.

Full body movement can also be determined, for example, by processingsuccessive visual captures taken by one or more cameras of the device inorder to identify/determine the identity, position, angles, speed,distance and/or acceleration of objects (or parts thereof) or thebackground (e.g., the ceiling, the floor, the walls, the sky) insuccessive visual captures from the device change in such a way that aremore likely to be caused by full body movement that partial devicemovement.

Full body movement can also be determined, for example, using a pressuresensor of the device to detect changes in elevation (which can beindicative, for example, of the user riding on an escalator, elevator,ladder or of shelf-picker use). From the time that such movement isdetermined to have started, until some time after as it is determined tohave ended, one or more restrictions can be employed (e.g., a lockscreencan be shown, phone calls are not allowed in our out, etc.) at/inrelation to the device.

Full body movement can also be determined, for example, by monitoringthe identify (and/or changes thereto) of the beacons (e.g. sound, RF,optical) and/or strength of the signals (and/or changes thereto) of thebeacons, that the device can perceive, for patterns indicative of fullbody movement (e.g., sufficiently large changes to signal strength fromone or more beacons). This may particularly useful in locations wheresuch infrastructure has already been deployed like a manufacturingfloor, e.g., for asset tracking.

It should be noted that certain techniques described herein can be moreuseful when applied (i) only within certain geographic areas (e.g., on amanufacturing floor, in a stairwell, on a sidewalk), the presence of adevice in such areas (e.g., geo-fences which may be static or dynamic)can be detected using one or more sensors and/or radios on the device(Win, cellular, GPS, BT, cameras, microphones); or (ii) within certaindate/time windows (e.g., allowing walking on manufacturing floor using amobile device after manufacturing hours).

It should be noted that, in certain implementations, the variousdeterminations described herein may be directed towards determiningwhether any activity is being performed with respect to which the device(and/or the user) is likely to be moving beyond a range in which it canbe moved by the user moving only his arms and/or standing/bending (e.g.,in contrast to, for example, determining the type of activity beingperformed). Such determination can reflect, for example, that movementof the device is outside an envelope that defines the positions andorientations that a device can be in without its user's feet changingtheir 3D position (and, in some cases, only if such activity isperformed within a certain location).

It should be understood that the movement detection techniques describedherein, also include scenarios in which the device user may be movingwith or near her device, but is not in direct physical contact with suchdevice (e.g., the device may be resting on, docked to, mounted on a cartthat the user is operating, pushing or walking next to).

It should be noted that, it certain situations, the ability todifferentiate between patterns indicative of partial-body movements,full-body movements and no movements, can also be utilized in additionalcontexts and settings. For example, one or more restrictions can beemployed at/in relation to a device until some time after (and then,optionally, for as long as) a pattern indicative of full body movement(or even of partial body movement) can be determined. For example,mobile device that is used to monitor processes on an industrial machinecan be motion activated (e.g., to activate the screen, CPU, etc.), asthere may otherwise be no need to activate such a device until such timeas the machine begins working. It should be understood that the devicecan determined that the machine has started/stopped working, forexample, via motion sensors in contact with the machine, e.g., via thesound of the machine or a signal emitted when the machine starts/endsand/or while it is in operation. By way of further example, operation ofa device can be allowed while walking on the floor, butprevented/restricted while the operator is very close to a machine(e.g., and must concentrate on operation of the machine).

It should be noted that, in certain implementations, various techniquessuch as those described herein which may reduce battery usage can beemployed in conjunction with the techniques described herein.

Described herein in various implementations are techniques andtechnologies that enable the collection of data and the computation ofvarious determinations with respect to the experiences (e.g., mood,activity level, engagement level, other behaviors, etc.) of users/people(e.g., patrons, workers, viewers, etc.) at a venue (e.g., club, party,concert, festival, park, town square, show, movie, sporting event,restaurant, including sub-venues (e.g., different parties on differentfloors of a club, different sections in a concert), and includingvirtual venues (e.g., those users watching a live event via theInternet) etc.), such as based on various inputs originating at sensorsincorporated within one or more of their mobile devices (e.g., phones,wearable devices, implantable devices, etc.) and/or one or originatingat the sensors of one or more external devices (e.g., a camera, amicrophone) in the vicinity. As described herein, in certainimplementations various crowd-sourcing techniques (with passive and/oractive components) can be utilized in collecting/receiving suchdata/inputs and/or computing such determinations.

For example, input(s) originating from various sensors of the mobiledevices of those present in a particular venue can be processed in orderto determine various characteristics of the crowd's experience (e.g., ata given point in time, over the course of an evening, etc.). In certainimplementations, aspects of such an experience can be determined, forexample, based on the frequency, duration, intensity, happiness leveland/or continuousness of dancing (as can be determined, for example,based on one or more patterns/sensor profiles, such as patternsexhibited by inputs originating from an accelerometer and/or gyroscopeor physiological/biometric monitoring using device sensors like heartrate monitoring, blood pressure, brain activity monitoring usingtechniques and sensors like EEG, fMRI, PET, etc., that correspond todancing) (as opposed to standing, sitting, or performing various actionsthat may be determined or identified to be indicative of boredom ordisengagement with the entertainment at the venue, e.g., playing a videogame, etc.). In doing so, real-time and/or retrospective feedback can begenerated and/or provided, reflecting, for example, which songs,settings, moods, etc., were most popular and which weren't, etc.

Additionally, in certain implementations such crowd experience data canbe compared, for example, over/across multiple venues. In certainimplementations, such a comparison can be performed in real-time and/orquasi real-time (based on which it can be determined, for example, atwhich venue are the individuals dancing most actively at a given time,during a given night, etc.), over time (e.g., how is the mood of patronsin Studio 45 this Friday night as compared to its average Friday nightperformance?) and/or with respect to an individual (e.g., how activelyam I dancing tonight as compared to others? Compared to others in thevenue that I'm in? Others my age? Relative to my usual activity level?,etc.).

In one implementation, a disk jockey (‘DJ’) in a nightclub or aperformer at a concert/performance can utilize inputs originating fromand/or reflecting the venue's conditions (such as can be collectivelyperceived by the sensors from patrons' mobile devices and/or externaldevices) to receive and/or determine real-time and/or near real-timefeedback from the current crowd. In doing so, the DJ, performer, etc.can better understand how various aspects of a particular song (orsongs) or performance selection (or selections) is being received by thecrowd (e.g., with respect to the genre, songs, tempo, volume, mixes,transitions, etc.), and the DJ/performer can take one or more actions(e.g., maintaining the same type of music/performance, making changes tothe music/performance, etc. and/or can learn from the feedback toimprove future engagements). Additionally, in certain implementationsvarious suggestions and/or recommendations can be generated (e.g., basedon the referenced feedback) and/or provided to the DJ/performer.

In another implementation, the conditions of different venues can bedetermined and made available to users (e.g., via a mobile device app, aweb application, etc.), such as in order to assist them in selectingwhich venue to visit (e.g., which clubs in my locale are “hot” tonight?which are playing the type of music that I like? at which are users likeme (e.g., those that enjoy similar music, are the same age) having abetter time at tonight?) or to socialize their experience (e.g., to postinformation about their venue choices, experiences and “performance”).

In another implementation, a venue can use information regarding theconditions in it to (i) better identify/target the people invites and/orthe places it advertises; (ii) make better decisions when booking talent(e.g., musicians/DJs), such as based on the characteristics identifiedwith respect to the previous performances of different artists andchoosing and/or pricing future artists more intelligently; and/or (iii)better target the partygoers/dancers for promotions in each venue.

FIG. 70 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 7010, one or more inputs can be received. In certain implementations,such inputs can be received in relation to one or more environmentalaspects. Examples of such environmental aspects include but are notlimited to: one or more content items and/or one or more demographicprofiles.

At 7020, the one or more inputs can be processed. In doing so, one ormore user experience characteristics can be computed. In certainimplementations, such user experience characteristics can be computedwith respect to and/or based on the one or more environmental aspects.

At 7030, one or more recommendations can be provided. In certainimplementations, such recommendations can be provided based on/inresponse to the one or more user experience characteristics. In certainimplementations, such recommendations can include but are not limitedto: one or more recommendations with respect to the one or more contentitems and/or one or more recommendations with respect to the one or moredemographic profiles.

By way of further illustration, in certain implementations the time togain entrance to a location (e.g., a club, the ticket counter at aconcert, the teller at the passport office, etc.) can be determinedbased on information received from various sensors on the mobile devicesof people waiting on line. For example, the devices of users that are insufficiently close proximity to a location can have their waiting timemonitored passively (e.g., using techniques known to those of ordinaryskill in the art, such as using device sensors such as GPS, Win,cellular, Bluetooth, microphones, physiological/biometric monitoringusing device sensors like heart rate monitoring, blood pressure, brainactivity monitoring using techniques and sensors like EEG, fMRI, PET,etc.) and/or actively (e.g., by having the user provide (and thenpossibly confirming) that they have entered/exited the line or thelocation).

FIG. 75 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 7510, one or more inputs can be received, such as from one or moredevices. Examples of such inputs include but are not limited to motioninputs (e.g., dancing) and/or audio inputs (e.g., singing out loud).

At 7520, the one or more inputs can be correlated, such as with one ormore first acoustic elements that are perceptible to the one or moredevices. Examples of such first acoustic elements include but are notlimited to one or more first songs. In doing so, an association can bedrawn between the inputs (e.g., corresponding to dancing and/or signing)and one or more songs that are playing concurrently.

At 7530, one or more suggestions can be generated. In certainimplementations, such suggestions can be generated based on a degree ofcorrelation between the one or more inputs and the one or more firstacoustic elements. Moreover, in certain implementations such one or moresuggestions can be generated with respect to one or more second acousticelements. Examples of such second acoustic elements include but are notlimited to other songs that are of the same genre as the first song. Forexample, upon determining (e.g., based on the referencedsinging/dancing) that a user enjoys a first song, one or more othersongs that are related/associated (e.g., by the same artist, of the samegenre, etc.) can be identified and/or suggested to the user.

By way of further illustration, in certain implementations,characteristics of peoples' enjoyment of music (as can be expressedand/or identified, for example, based on motion, singing out loud), ascan be perceived by sensors of mobile devices (e.g., motion sensors,microphones, cameras, proximity and light sensors, various RF radios,user content (e.g., camera usage, communications usage, applicationusage), physiological/biometric sensors (e.g., heart rate monitors,breath rate, GSV) and brain activity sensors), that are near to, incontact with, worn by or inside them can be correlated with differenttypes of music (e.g., of a particular genre, specific songs as can bedetermined by technologies such as Shazam), to determine the musicalpreferences of a user or users. Such preferences can then be used bysuch people themselves (e.g., to discover or rediscover new songs andartists, to create more enjoyable music playlists for differentsituations, to find and meet people who have certain preferences formusic or dance (e.g., highly similar, exactly opposite, substantiallyuncorrelated, etc.) and/or by 3^(rd) parties (e.g., DJs in a club whocan refine/improve/be more confident with their selection of music whenthey better know the preferences of their crowd or clubs can targetadvertising to people who are more likely to enjoy the type of musicthey are planning to play on a particular night/time).

FIG. 71 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 7110, one or more inputs can be received. In certain implementations,such inputs can be received from one or more devices, such as devicesthat are present in one or more locations. Moreover, in certainimplementations such inputs can correspond to one or more environmentalaspects of the one or more locations.

At 7120, the one or more inputs can be processed. In doing so, one ormore characteristics of the one or more locations can be determined.

At 7130, one or more actions can be initiated. In certainimplementations, such actions can be initiated with respect to the oneor more locations. Moreover, in certain implementations such actions canbe initiated based on the one or more characteristics.

FIG. 72 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 7210, one or more inputs can be received. In certain implementations,such inputs can be received from one or more (and/or from a pluralityof) devices, such as devices that are present in a particular location.Moreover, in certain implementations, each of the one or more inputs caninclude demographic information associated with one (or more) of the oneor more devices. For example, the age of users within a particular spaceor venue can be received.

At 7220, the one or more inputs can be processed. In doing so, one ormore actions can be selected. Moreover, in certain implementations suchactions can be selected based on the demographic information.Additionally, in certain implementations the one or more inputs can beprocessed to select content associated with the demographic information.For example, one or more advertisements (which are to be deployed on abillboard in a place where the referenced users are present) can beselected.

At 7230, at least one of the one or more actions can be initiated. Incertain implementations, such actions can be initiated in relation tothe location. For example, content (such as that selected at 7220—e.g.,the referenced advertisements that are selected) can be provided withrespect to the location.

By way of further illustration, in certain implementations thedemographic characteristics of a venue or area, aggregated acrossmultiple users (e.g., crowd-sourced) can be used to determine an actiontaken that may affect multiple users. For example, based upon thedemographic characteristics in Times Square each minute, theadvertisement that is to be shown on one or more large billboards can beselected in some way (e.g., through a bidding process). Such demographiccharacteristics can be acquired in real-time and/or based on historicalinformation. Or, for example, based upon the demographic and activitycharacteristics in Times Square where an advertiser wants the real-timedemographic, but only for those people who are currently walking.

In certain implementations, a database of information relating to thevarious devices can be maintained and/or accessed by/via 3rd parties(e.g., Facebook), such as in order to estimate additional venuecharacteristics and/or patron characteristics and changes thereto, suchas in real-time/near real-time. For example, (i) the age/genderdistribution of the patrons and other demographic info (e.g., maritalstatus, education level, income level, home location) in an venue and/orin a particular location; (ii) the population density of an venue (isthe club crowded? is the restaurant seating more than its allowed topursuant to fire codes?); average visit time (longer time at some venuesmight be considered a good sign (e.g., a club), while at other venues abad sign (e.g., a passport office), etc.

FIG. 73 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 7310, one or more inputs can be received. In certain implementations,such inputs can be received from one or more devices, such as devicesthat are present in a location. Moreover, in certain implementations,each of the one or more inputs can include demographic information, suchas demographic information associated with one of the one or moredevices. For example, demographic information can be received withrespect to users that are present at/in proximity to a nightclub or arestaurant.

At 7320, the one or more inputs can be processed. In doing so, ademographic profile can be computed, such as with respect to thelocation. In certain implementations, such a demographic profile can becomputed, based on the demographic information. For example, anaggregate demographic profile (e.g., an average age) can be computed.

At 7330, one or more recommendations can be provided. In certainimplementations, such recommendations can be provided with respect tothe location. Moreover, in certain implementations such recommendationscan be provided based on the demographic profile. For example, variousmenu changes can be generated and provided to a restaurant owner inorder to appeal to the demographic currently present (e.g., ‘happy hourspecials,’ etc.).

By way of further illustration, in certain implementations the aggregatedemographic data at different locations over time can be compared. Indoing so, it can be determined how a current demographic at a venuecompares to demographics at this venue over time (e.g., a particularvenue may be at an all-time high for young male patrons) and/or incomparison to other venues (e.g., while were attracting mostly women,aged 30-39, we have far fewer such women than other businesses like us).In doing so, various suggestions can be generated and/or provided. Forexample, a suggestion can be generated for a restaurant owner in orderto optimize his fare/pricing for the demographic that frequents hisvenue. By way of further example, a 28 year old man wants to go clubbingto meet women and a suggestion can be generated and/or providedindicating in which club the current real time demographic (e.g., age,gender) best suites his wishes.

FIG. 74 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 7410, one or more inputs can be received. In certain implementations,each of the one or more inputs can be received with respect to apresentation of a first content item (e.g., a first segment or sectionof a content item such as a movie). For example, the referenced inputscan be received from respective mobile devices, each of which can beassociated with a viewer of a movie. Examples of such inputs include butare not limited to biometric inputs (e.g., heart rate, etc.) and brainactivity monitoring (using techniques and sensors like EEG, fMRI, PET,etc.).

At 7420, the one or more inputs can be processed. In doing so, feedbackcan be determined, such as with respect to the first content item. Forexample, as described herein, based on the received inputs it can bedetermined how the referenced users/viewers reacted to the first contentitem (e.g., whether they did/didn't enjoy the segment and/or to whatdegree, whether they were frightened by it and/or to what degree, etc.).

At 7430, a second content item can be selected, such as forpresentation. In certain implementations, such a second content item canbe selected for presentation based on the feedback. For example, asdescribed herein, having determined that a first segment of a moviefrightened a substantial number of the users/viewers, a subsequentsegment (which may be relatively less frightening) can be selectedand/or provided. By way of further example, as describe herein, havingdetermined that one segment of a movie was particularly enjoyable to asubstantial number of the users/viewers, a comparable segment can beselected and/or subsequently provided.

By way of further illustration, in certain implementations a contentcreator such as a movie producer can test various candidate scenes ondifferent groups to see how the scenes are received (and/or how thereactions to such scenes correspond to various audience demographics).Using this information, the movie producer can choose which of thecandidate scenes to include in the movie, can choose if/how to customizemovies released in different locations (e.g., different countries), suchas by including (or excluding) different scenes based on the feedbackreceived from users associated with the demographic of such location.

In another implementation, a movie producer can create a movie which mayunfold differently based upon various predictions and/or determinationsas to how a particular audience will react (e.g. by customizing themovie in a manner that will be best received by the audience). Forexample, audience reaction to one or more scenes of a movie up until thecurrent time in the movie (e.g., as determined based on inputs receivedfrom mobile devices and/or external devices (e.g. in-seat devices,in-floor devices) associated with viewers of the movie) can be used todetermine which of one or more scenes is to be shown (or not shown) inthe remainder of the movie. For example, if the audience in a particulartheatre had abnormally high spikes in heart rate and blood pressureduring the first scary scene of the movie, the remainder of the moviecan be adjusted such that a “less scary” version is shown (or perhapsthe reverse if the intention is to deliver a scary user experience). Inanother example, if a sufficiently significant portion of a viewingaudience demonstrates aggregate brain activity indicating greater thanusual positive (or negative) feelings of a particular kind (e.g.,happiness, satisfaction) when a beautiful nature scene is shown, theremainder of the movie can be adjusted/modified or “tilted” (e.g., inreal-time) towards including (or excluding) additional nature-basedscenes (e.g., where available and appropriate).

In another example, the demographic composition of a viewing audiencecan be used (e.g., in conjunction with the audience reaction or alone)to determine which of one or more scenes is to be shown (or not shown)in (the remainder of) the movie. For example, for a younger demographicthe movie might contain a scarier scene, but, if, despite beingapplicable for the audience demographic, the audience reactiondemonstrates an undesirable effect (e.g., stress beyond normal for thedemographic, etc.), a less scary form of the next available scene (ifavailable) can be chosen.

In certain implementations, inputs originating from various motionsensors (e.g., on mobile devices) can be processed in order todetermine/identify when and/or how much viewers ‘jump’ at scary scenes,laugh at jokes, etc. (e.g., during a TV show or movie). Suchdeterminations (e.g., with respect to individual users) can also becombined/aggregated, based on which the collective user experience withrespect to various scenes and/or cinematic techniques can be furtherdetermined.

Moreover, in certain implementations various alternative pieces ofcontent (e.g., scenes, endings, etc.) can be tested, and thereceived/determined feedback (such as is described herein) can beutilized to identify, for example, which scenes generate more positive(or a desired—e.g., fright in the case of a horror movie)reaction(s)/response(s). Additionally, as noted, works (e.g., movies,etc.) that unfold differently based upon the audience mood/reactions canbe created and/or presented (e.g., custom, audience-optimizedperformances).

FIG. 76 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 7610, one or more inputs can be received. In certain implementations,such inputs can be received from one or more devices, such as devicespresent in one or more locations. Moreover, in certain implementationssuch inputs can correspond to one or more environmental aspects of theone or more locations, such as is described herein.

At 7620, the one or more inputs can be processed. In doing so, one ormore characteristics of the one or more locations can be determined,such as is described herein.

At 7630, one or more recommendations can be provided. In certainimplementations, such recommendations can be provided, based on the oneor more characteristics. Moreover, in certain implementations the one ormore recommendations can be provided with respect to the one or morelocations, such as is described herein.

In certain implementations, it should be understood that the referencedinputs can include inputs from sensors such as cigarette-smoke sensors,other air quality sensors like CO2, CO, temperature, etc. (based onwhich various aspects such as environmental factors can be determined,such as are referenced herein).

It should be understood that the techniques and technologies describedherein can be expanded/improved to provide data and services about otherforms of entertainment such as stand-up comedians and sporting events(e.g., measuring the laugher level or cheering level perceived by thedevices microphones and analyzed using techniques known to those ofordinary skill in the art), movies (e.g., measuring how engrossed theuser is by the lack of movement of the motion sensors on a mobiledevice), music (e.g., a tool to help artists get passive real-timefeedback from their audience and recommend ways to improve performance),advertising (e.g., delivering “mood-based” advertisements, etc.).Additionally, it should be understood that the referencedrecommendation(s) can be made passively (e.g., posting to a website) oractively (e.g., vibrating a user's device).

A geo-fence (as can be employed or implemented using any number oftechnologies or techniques, including but not limited to Win, cellular,GPS, Bluetooth, etc., as is known to those of ordinary skill in theart), when used in certain ways can be an accurate and power efficienttechnique for monitoring the movement of a mobile device. Usinggeo-fences in a manner that allows for a low-power consumption methodfor monitoring device movement can be advantageous in systems thatselectively restrict usage of a device determined to be associated withor operated by a driver, such as while in a moving vehicle. In order tomonitor/determine when a device begins to move (as opposed to when, forexample, one passes the grocery store on the way home), a geo-fence canbe ‘erected’ or defined around/with respect to the location of a deviceand can be configured to provide notifications (e.g., to variousinterested parties such as the ‘erector’ of the geo-fence) and/orinitiate various other actions, such as when a device is determined tohave moved out of a geo-fenced area (i.e., an exit geo-fence). However,as described herein, in lieu of/in addition to monitoring a device'smovement via a single geo-fence (e.g., around its current location), acoordinated arrangement/system of multiple geo-fences can be employed,through the use of which improved determinations can be made, such asdetermining whether a device has begun a trip and/or is still moving(e.g., within a vehicle). For example, as a device moves, it can exit orenter different areas in the system of geo-fences (e.g., differentgeo-fences that are adjacent or otherwise proximate to one another),based upon which one or more notifications can be provided and/or one ormore actions initiated (e.g., using processes on the device or externalto the device) in a manner that is relatively faster, more efficient,and/or more accurate than can be achieved using a single geo-fence and,in many cases, more power efficient than using GPS alone. For example,it can be appreciated that, under certain circumstances, entrygeo-fences may react to the presence/entry of a device more quickly thanexit geo-fences will react to the non-presence/exit of the device (e.g.,geo-fencing systems that rely on WiFi as a first technique or interfacefor determining entry/exit, such as for reasons of power efficiency, maycause an entry geo-fence to react nearly immediately upon the detectionof one or more WiFi access points in a list of access points whereas anexit geo-fence may react more slowly, by requiring confirmation overtime that no WiFi access points within a possibly different list ofaccess points are present (e.g., to reduce false positive geo-fencebreaks/exits by differentiating between the case of a true geo-fencebreak from the case where the device hasn't broken a fence, buttemporarily doesn't receive signals from one or more WiFi access points(e.g., the WiFi access point was turned off, the signal is blocked by awall)) and/or some form of affirmative or positive confirmation).

FIG. 77 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both.

At 7710 it can be determined that a device exited one or more firstlocations (and/or regions and/or areas) and/or entered one or moresecond locations (and/or regions and/or areas). In certainimplementations, such first and second locations can be defined orotherwise arranged such that the one or more second locations surround(whether partially—e.g., from one or more sides—or entirely) the firstlocation(s). Moreover, in certain implementations the referenced secondlocations can be configured or otherwise arranged such that they doand/or do not overlap with one another.

Additionally, in certain implementations the referenced first locationsand/or second locations can be defined by a perceptibility of anotherdevice (e.g., an access point, cell tower, etc.). Moreover, in certainimplementations the size (e.g., the radius, area, length, otherdimensions, etc.) of the first locations and/or the second locations canbe determined based on a metric such as a density metric. Examples ofsuch a metric/density metric include but are not limited to: a densityof one or more devices, a population density, a traffic light density,one or more speed limits, a tree density, and/or a quantity of vehiclesowned per capita.

By way of further illustration, in order to improve the responsivenessof a geo-fencing system, such as with respect to movement (e.g., inorder to achieve higher accuracy and/or lower latency) anarrangement/collection of multiple exit and/or entry geo-fences (which,in certain implementations may and may not overlap with one another) canbe established or otherwise defined. Doing so can be advantageous, forexample, in order to provide enhanced protection to drivers and/orpassengers within a vehicle as well as other road users against theperils of distracted driving (e.g., by enabling quick/accuratedeterminations as to whether a vehicle is traveling, has departed alocation, etc.). In one implementation, a system or arrangement of eight(8) circular entry geo-fences (e.g., of equal radius) and one circularexit geo-fence can be defined or ‘erected,’ whereby (i) the entrygeo-fences, together, substantially circumscribe the exit geo-fence,(ii) the exit geo-fence is of smaller radius than the others (e.g., inorder to reduce the latency of detecting an exit) and/or the entrygeo-fences are of larger radii (e.g., to increase the likelihood thatthe device will be perceptible within such geo-fences before exitingthem), (iii) the referenced geo-fences (entry and exit geo-fences) arearranged/defined such that they do not overlap with one another (inother implementations some or all of them may overlap one another),and/or (iv) the center of the exit geo-fence can be defined based on acurrent location of the device (e.g., a current estimated location). Oneexemplary scenario of an arrangement of geo-fences is depicted in FIG.78.

Moreover, in certain implementations a system/arrangement of multiplegeo-fences can be employed in lieu of (or in addition to) a singlegeo-fence. In doing so, a smaller/finer/more precise geo-fence system(than may otherwise be possible using a single geo-fence) can beemployed. By way of illustration, in certain implementations anarrangement/system of four circular exit geo-fences (e.g., having equalradii) can be defined or ‘erected’ such that each geo-fence overlapseach of the others, such as is shown in FIG. 79. In doing so, thegeo-fencing system can be more responsive to movement (e.g., thegeo-fence will break after a smaller distance movement and/or shortertime), than in scenarios in which the minimum size of a geo-fence islimited (e.g., by a device's operating system, hardware, industrystandards, etc.).

It should be understood that while various illustrations of thereferenced geo-fences pertain to circular geo-fences, variousarrangements of such geo-fences, etc., in other implementations (i) thegeo-fences may be other shapes (e.g., polygonal), (ii) the geo-fencesmay be arranged in different numbers and/or combinations of exit andentry geo-fences, (iii) two or more of the geo-fences may overlap oneanother, (iv) the radii of the geo-fences (or the dimensions of thegeo-fences) may not be equal, and/or (v) some or all of the geo-fencescan be ‘entry’ geo-fences, ‘exit’ geo-fences, and/or a combinationthereof.

At 7720, one or more actions can be initiated, such as with respect tothe device (e.g., the device determined to have exited/entered thefirst/second location(s). By way of illustration, one or morerestrictions (e.g., restrictions of the device) can be modified at/inrelation to the device. Moreover, in certain implementations suchactions can be initiated based on a determination that the device hasexited one or more of the first location(s) and/or entered one or moreof the second location(s).

By way of illustration, in certain implementations the size(s) of thereferenced geo-fences can be selected/identified/determined or otherwisedefined based on a metric that reflects the density of various devicessuch as wireless transmitters (e.g., Win, cellular, GPS, Bluetooth,etc.) and/or one or more other metrics (e.g., population density,traffic light density, speed limits, tree density, vehicles owned percapita per region, etc.). For example, with respect to an implementationof the described geofencing system/arrangement in a densely populatedurban area (e.g., New York City), the size of one or more (or all) ofthe geo-fences in the system/arrangement can be smaller (therebyreducing latency). It can be appreciated that despite utilizingrelatively smaller geo-fences in such a densely populated area (e.g., ascompared to a less densely populated are) is not likely to substantiallyreduce the ability to determine that a vehicle is passing through (e.g.,entering/exiting) the various geo-fences, since vehicles traveling insuch an urban area are likely to travel at relatively slower speeds (atwhich it is relatively simpler (e.g., relatively slower sampling ratesare required) to detect an entry/exit of the device from a particulargeo-fence). With respect to a rural area, the size of one or more (orall) of the geo-fences in the system/arrangement can be relativelylarger/increased. In doing so, the ability to determine that a vehicleis passing through (e.g., entering/exiting) the various geo-fences canbe increased (e.g., relative to a fixed signal sampling rate), sincevehicles traveling in such a rural area are likely to travel atrelatively faster speeds (at which it may be relatively more difficultor power intensive (e.g., require a higher sampling rate) to detect anentry/exit of the device from a particular geo-fence).

It should be noted that U.S. patent application Ser. No. 13/244,978,filed Sep. 26, 2011 (now U.S. Pat. No. 8,290,480), International PCTApplication No. PCT/US2011/052655, filed Sep. 21, 2011, InternationalPCT Application No. PCT/US2012/030017, filed Mar. 21, 2012,International PCT Application No. PCT/IB2013/001582, Filed Jun. 21, 2013(each assigned to the present applicant) may be relevant to variousaspects described herein, and each of the referencedapplications/patents is hereby incorporated by reference herein in theirrespective entireties.

At this juncture, it should be noted that although much of the foregoingdescription has been directed to systems and methods for determininguser roles and/or devices usages within the context of vehicular travel,the systems and methods disclosed herein can be similarly deployedand/or implemented in scenarios, situations, and settings far beyond thereferenced scenarios. It can be readily appreciated that the user-roledetermination system 100 can be effectively employed in practically anyscenario where the determination and/or identification of a user orusage of a mobile device is of value, such as in the context ofexercising or game playing. It should be further understood that anysuch implementation and/or deployment is within the scope of the systemsand methods described herein.

It is to be understood that like numerals in the drawings represent likeelements through the several figures, and that not all components and/orsteps described and illustrated with reference to the figures arerequired for all embodiments or arrangements. It should also beunderstood that the embodiments and/or arrangements of the systems andmethods disclosed herein can be incorporated as a software algorithm,application, program, module, or code residing in hardware, firmwareand/or on a computer useable medium (including software modules andbrowser plug-ins) that can be executed in a processor of a computersystem or a computing device to configure the processor and/or otherelements to perform the functions and/or operations described below. Itshould be appreciated that according to at least one embodiment, one ormore computer programs or applications that when executed performmethods of the present invention need not reside on a single computer orprocessor, but can be distributed in a modular fashion amongst a numberof different computers or processors to implement various aspects of thesystems and methods disclosed herein.

Thus, illustrative embodiments and arrangements of the present systemsand methods provide a computer implemented method, computer system, andcomputer program product for selectively restricting a mobile device.The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments and arrangements. In this regard, each block in theflowchart or block diagrams can represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising”, when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

It should be noted that use of ordinal terms such as “first,” “second,”“third,” etc., in the claims to modify a claim element does not byitself connote any priority, precedence, or order of one claim elementover another or the temporal order in which acts of a method areperformed, but are used merely as labels to distinguish one claimelement having a certain name from another element having a same name(but for use of the ordinal term) to distinguish the claim elements.

Also, the phraseology and terminology used herein is for the purpose ofdescription and should not be regarded as limiting. The use of“including,” “comprising,” or “having,” “containing,” “involving,” andvariations thereof herein, is meant to encompass the items listedthereafter and equivalents thereof as well as additional items.

The subject matter described above is provided by way of illustrationonly and should not be construed as limiting. Various modifications andchanges can be made to the subject matter described herein withoutfollowing the example embodiments and applications illustrated anddescribed, and without departing from the true spirit and scope of thepresent invention, which is set forth in the following claims.

What is claimed is:
 1. A method comprising: computing one or morenavigation instructions between a first location and a second location;processing, with a processing device, the one or more navigationinstructions in relation to at least one of (a) one or more previouslycomputed navigation instructions between the first location and thesecond location or (b) a previously traveled route between the firstlocation and the second location to determine one or more disparitiesbetween the one or more navigation instructions and the at least one of(a) one or more previously computed navigation instructions between thefirst location and the second location or (b) a previously traveledroute between the first location and the second location; and generatingone or more notifications based on the one or more disparities.
 2. Themethod of claim 1, wherein the one or more notifications comprise one ormore navigation instructions that characterize an aspect of thenavigation between the first location and the second location inrelation to the at least one of (a) one or more previously computednavigation instructions between the first location and the secondlocation, (b) a previously traveled route between the first location andthe second location, or (c) a frequently traveled route between thefirst location and the second location.
 3. The method of claim 1,wherein the one or more notifications comprise one or more navigationinstructions that characterize an aspect of the navigation between thefirst location and the second location as an instruction to deviate fromat least one aspect of the at least one of (a) one or more previouslycomputed navigation instructions between the first location and thesecond location or (b) a previously traveled route between the firstlocation and the second location.
 4. The method of claim 1, wherein theone or more notifications comprise one or more navigation instructionsthat characterize an aspect of the navigation between the first locationand the second location as an instruction to continue performing atleast one of the one or more navigation instructions that werepreviously provided.
 5. The method of claim 4, further comprisingproviding the one or more notifications in relation to a locationassociated with the one or more disparities.
 6. The method of claim 4,wherein the at least one of the one or more navigation instructions werepreviously provided during the same trip as the one or more navigationinstructions.
 7. The method of claim 1, wherein the one or morenotifications comprise one or more navigation instructions thatcharacterize an aspect of the navigation between the first location andthe second location as an instruction to continue performing at leastone navigation operation.
 8. The method of claim 7, wherein the at leastone navigation operation comprises a navigation operation that wasperformed.
 9. The method of claim 7, further comprising providing theone or more notifications in relation to a location associated with theone or more disparities.
 10. The method of claim 7, wherein the at leastone navigation operation was previously performed during the same tripas the one or more notifications are generated with respect to.
 11. Themethod of claim 1, further comprising precluding the providing of anotification that does not correspond to the one or more disparaties.12. A system comprising: a memory; and a processing device, operativelycoupled to the memory, to: receive a first set of navigationinstructions, the first set of navigation instructions comprisingnavigation instructions from a first origin to a first destination;receive a second set of navigation instructions, the second set ofnavigation instructions comprising navigation instructions from a secondorigin to a second destination; process the first set of navigationinstructions and the second set of navigation instructions to determineone or more disparities between the first set of navigation instructionsand the second set of navigation instructions with respect to one ormore locations; generate one or more notifications based on the one ormore disparities; and provide the one or more notifications in relationto the one or more locations.
 13. The system of claim 12, wherein thesecond set of navigation instructions comprises at least one of (a) oneor more previously traveled routes, (b) one or more frequently traveledroutes, or (c) one or more previously computed navigation instructions.14. The system of claim 12, wherein at least one of (a) the first originis equivalent to the second origin or (b) the first destination isequivalent to the second destination.
 15. The system of claim 12,wherein to process the first set of navigation instructions and thesecond set of navigation instructions is to processing the first set ofnavigation instructions and the second set of navigation instructions todetermine (a) one or more instructions that are present in both thefirst set of navigation instructions and the second set of navigationinstructions and (b) one or more disparities between the first set ofnavigation instructions and the second set of navigation instructions,the one or more disparities comprising one or more instructions thatfollow the one or more instructions that are present in both the firstset of navigation instructions and the second set of navigationinstructions that are at least one of (a) present in the second set ofnavigation instructions but are not present in the first set ofnavigation instructions or (b) present in the first set of navigationinstructions but are not present in the second set of navigationinstructions.
 16. The system of claim 15, wherein the one or morenotifications comprise at least one of (a) a notification not to performone or more instructions from the first set of navigation instructionsthat are associated with the one or more locations and that are notpresent in the second set of navigation instructions or (b) anotification to perform one or more instructions from the second set ofnavigation instructions that are associated with the one or morelocations and that are not present in the first set of navigationinstructions.
 17. The system of claim 12, wherein to provide the one ormore notifications is to provide the one or more notifications via oneor more interfaces.
 18. The system of claim 17, wherein the one or moreinterfaces comprise at least one of: a display interface, an audiointerface, an illumination interface, or a haptic interface.
 19. Thesystem of claim 17, wherein to provide the one or more notifications viaone or more interfaces is to: determine a degree to which the one ormore notifications are relatively unlikely to be complied with; andselect, based on the degree to which the one or more notifications arerelatively unlikely to be complied with, at least one of the one or moreinterfaces at which to provide the one or more notifications.
 20. Thesystem of claim 12, wherein to provide the one or more notifications isto provide the one or more notifications in a manner that is relativelymore prominent than one or more notifications provided with respect toone or more prior navigation operations.
 21. The system of claim 20,wherein to provide the one or more notifications is to: determine adegree to which the one or more notifications are relatively unlikely tobe complied with; and provide, based on the degree to which the one ormore notifications are relatively unlikely to be complied with, the oneor more notifications in a manner that is relatively more prominent thanone or more other notifications provided with respect to the one or moreprior navigation operations.
 22. The system of claim 12, wherein toprovide the one or more notifications is to provide the notification ina manner that is at least one of (a) relatively louder, (b) relativelyfaster, (c) relatively brighter, (d) relatively stronger; (e) relativelylonger, (f) relatively more redundant, (g) relatively more dynamic, (h)relatively bolder, or (i) relatively larger, than one or morenotifications provided with respect to the one or more prior navigationoperations.
 23. The system of claim 12, wherein the processing device isfurther to preclude the providing of a notification that does notcorrespond to the one or more disparities between the first set ofnavigation instructions and the second set of navigation instructions.24. A non-transitory computer-readable medium having instructions storedthereon that, when executed by a processing device, cause the processingdevice to: compute one or more navigation instructions between a firstlocation and a second location; process the one or more navigationinstructions in relation to at least one of (a) one or more previouslycomputed navigation instructions between the first location and thesecond location or (b) a previously traveled route between the firstlocation and the second location to determine one or more disparitiesbetween the one or more navigation instructions and the at least one of(a) one or more previously computed navigation instructions between thefirst location and the second location or (b) a previously traveledroute between the first location and the second location; generate oneor more notifications based on the one or more disparities, the one ormore notifications comprising one or more navigation instructions thatcharacterize an aspect of the navigation between the first location andthe second location as an instruction to continue performing at leastone of the one or more navigation instructions that were previouslyprovided; and provide the one or more notifications in relation to alocation associated with the one or more disparities.